Vendor_App and Helpers

[Paul M Jones-4]

Hi all,

Right now, each app can have its own view helpers to override the  
Vendor view helpers.

Vendor/
    App/
        Foo.php
        Foo/
            Helper/
                Bar.php


I'm starting to think this needs to be moved, or maybe discarded  
entirely in favor of vendor-only helpers.

My first thought is to move it to View/Helper, so that you can keep  
the overrides, but in a way that matches the class-name infix for  
View_Helper classes:

Vendor/
    App/
        Foo.php
        Foo/
            View/
                Helper/
                    Bar.php

This makes the class name overly long in my opinion:  
`Vendor_App_Foo_View_Helper_Bar`. However, the benefit is that we can  
add it to the Helper stack with no special logic; we can use  
Stack::setByParents('View_Helper') and it will work more "naturally"  
with the class hierarchy.

Second thought, more controversial, is to discard the Helper directory  
entirely and go with only Vendor-level view helpers.  That means no  
more app-level overrides of view helpers.

How many of you guys write app- or page-level helpers that override  
your own vendor-level view helpers?  (I have done exactly one, but  
only as an example of how to do it; in practice, everything seems to  
fit nicely in the Vendor-level view helpers.)

Any thoughts about this, for or against?



--

Paul M. Jones
http://paul-m-jones.com/




_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

[Jeff Moore-4]

On Aug 25, 2009, at 7:34 AM, Paul M Jones wrote:

> Second thought, more controversial, is to discard the Helper directory
> entirely and go with only Vendor-level view helpers.  That means no
> more app-level overrides of view helpers.

Fine with me.

Are there ANY non-trivial apps (the kind needing helpers) that don't  
also define a vendor namespace for other things?

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

[Jeff Surgeson]

> Second thought, more controversial, is to discard the Helper directory
> entirely and go with only Vendor-level view helpers.  That means no
> more app-level overrides of view helpers.
>
> How many of you guys write app- or page-level helpers that override
> your own vendor-level view helpers?  (I have done exactly one, but
> only as an example of how to do it; in practice, everything seems to
> fit nicely in the Vendor-level view helpers.)
>
> Any thoughts about this, for or against?

Also dont see a problem here, sounds ok!
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

[Jon Elofson]

Hello,
Most of the time I create a Vendor_App_Base application, which the
rest of my Vendor apps extend. Typically, I put my view helpers in
Vendor/App/Base/Helper/....

The idea of moving helpers into the View folder of an app is really
nice, but, like you said, creates crazy long class names, and probably
isn't necessary.


And by the way, I am very happy to hear about OmniTI's support of your
work. I believe it's a wise decision by them. Congratulations!

Jon

>
> Message: 2
> Date: Tue, 25 Aug 2009 09:34:59 -0500
> From: Paul M Jones <pmjones@...>
> Subject: [Solar-talk] Vendor_App and Helpers
> To: solar-talk@...
> Message-ID: <FA084157-34B9-4F98-A3C1-C87BF24C9353@...>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Hi all,
>
> Right now, each app can have its own view helpers to override the
> Vendor view helpers.
>
> Vendor/
>    App/
>        Foo.php
>        Foo/
>            Helper/
>                Bar.php
>
>
> I'm starting to think this needs to be moved, or maybe discarded
> entirely in favor of vendor-only helpers.
>
> My first thought is to move it to View/Helper, so that you can keep
> the overrides, but in a way that matches the class-name infix for
> View_Helper classes:
>
> Vendor/
>    App/
>        Foo.php
>        Foo/
>            View/
>                Helper/
>                    Bar.php
>
> This makes the class name overly long in my opinion:
> `Vendor_App_Foo_View_Helper_Bar`. However, the benefit is that we can
> add it to the Helper stack with no special logic; we can use
> Stack::setByParents('View_Helper') and it will work more "naturally"
> with the class hierarchy.
>
> Second thought, more controversial, is to discard the Helper directory
> entirely and go with only Vendor-level view helpers.  That means no
> more app-level overrides of view helpers.
>
> How many of you guys write app- or page-level helpers that override
> your own vendor-level view helpers?  (I have done exactly one, but
> only as an example of how to do it; in practice, everything seems to
> fit nicely in the Vendor-level view helpers.)
>
> Any thoughts about this, for or against?
>
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.com/
>
>
>
>
>
>
> ------------------------------
>

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

[Antti Holvikari-2]

On Tue, Aug 25, 2009 at 5:34 PM, Paul M Jones<pmjones@...> wrote:
> Second thought, more controversial, is to discard the Helper directory
> entirely and go with only Vendor-level view helpers.  That means no
> more app-level overrides of view helpers.

I've never used anything else than vendor-level helpers. Though, I can
see someone could have a (PEAR) "sub-package" that would provide
helpers. With helper overrides in the "sub-package" (app-level) you
end up keeping all files inside the package (Vendor/Subpackage). But
like I said, I've never needed app-level helpers (and we like Real
World Use Cases).

--
-antti
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

[Paul M Jones-4]

On Aug 27, 2009, at 12:37 , Antti Holvikari wrote:

> On Tue, Aug 25, 2009 at 5:34 PM, Paul M Jones<pmjones@paul-m-
> jones.com> wrote:
>> Second thought, more controversial, is to discard the Helper  
>> directory
>> entirely and go with only Vendor-level view helpers.  That means no
>> more app-level overrides of view helpers.
>
> I've never used anything else than vendor-level helpers. Though, I can
> see someone could have a (PEAR) "sub-package" that would provide
> helpers. With helper overrides in the "sub-package" (app-level) you
> end up keeping all files inside the package (Vendor/Subpackage). But
> like I said, I've never needed app-level helpers (and we like Real
> World Use Cases).

Preach it. :-)

OK, as of revisions [3983] and [3984] in branches/remodel, there are  
no more page-level view helper overrides.

Thanks, everyone, for your feedback and assistance on this.



--

Paul M. Jones
http://paul-m-jones.com/




_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk