Re: [SMARTY] Seperation of Logic and Presentation
boots <[email protected]>
| Newsgroups | gmane.comp.php.smarty.general |
|---|---|
| Message-ID | <[email protected]> |
Interesting. My solution (also a PHP5 class) is called SmartyDocInfo
(although I think that SmartyDoc might be more appropriate) and works
in a similar way except that I use some filter magic and have just two
addins/api methods to inject content into the header. Again, I wanted
to provide control to template users to be able to inject head
directives rather than forcing that in code. Take a look at the wiki if
you wish. I wouldn't mind seeing your code either if you want to mail
it to me or post it somewhere.
BTW: I like the idea of:
> $tpl->pageDisplay('defaultbikeparts.tpl', 'SimpleIntranetPageBase');
it is something I have been looking at adding in to my class but am
still wondering on the best way of doing so.
--- Jochem Maas <[email protected]> wrote:
> boots wrote:
> > The way I see it, how you organize is going to be largely dependant
> on
> > whether you choose to associate requests with actions or you rather
> > associate requests with views.
> >
>
> ...
>
> >
> > I am moving away from that because there is ever more creep of
> > presentation concerns into my business logic API. I am not quite
> back
> > to associating requests with views (though I am getting closer) and
> am
> > presently in a hybrid quagmire. The main barrier to associating
> views
> > with requests is that sub-templates typically can not add
> processing
> > information to the <head> of the rendered document meaning that an
>
> [what's below could get very boring very quickly for some people ;-)]
>
> I solved this problem with a subclass of Smarty (a php5 class I
> call SmartyPage). this class takes care of diplaying a header (the
> doc HEAD
> + opening TAG) the content (the actual viewable page) and a footer.
>
> my class has a pageDisplay() method which wraps 3 calls to
> Smarty::display/fetch()
> the content template is fetched first then the header is displayed,
> there after
> the fetched output from the content tpl is output and lastly the
> footer is
> displayed.
>
> My subclass class has 3 methods for injecting 'stuff' into the HEAD:
>
> SmartyPage::addJavascript( <url to js file> );
> SmartyPage::addStyleSheet( <url to css file>, <css media relevance
> e.g. 'screen' or 'print'> );
> SmartyPage::addJavascriptGlobalVar( <js var name>, <js var value> );
>
> I then have a few custom plugins that allow 'content' templates (and
> any
> subtemplates) to add stuff to the HEAD (which is actually always
> diplayed
> by way of the header tpl after the content tpl is fetched) e.g:
>
> {addjavascript file="/js/core/selectoptions.js"}
>
> In addition I have developed a class PageBase which is used to define
> default DOCTYPE, js files, css files, global js vars, header tpl,
> footer tpl - the PageBase
> class can be subclassed and the definitions in the superclass can be
> either augmented or overridden as required - the upshot is that I can
> create a
> small set of PageBase subclasses (very simple classes without
> methods) that specify how
> different kinds of pages (e.g. stdpages, popup pages, order
> transaction pages, etc)
> for a project to diplay a page with a given content template I call
> my subclass like so:
>
> $tpl->pageDisplay('defaultbikeparts.tpl');
>
> or
>
> $tpl->pageDisplay('defaultbikeparts.tpl', 'SimpleIntranetPageBase');
>
> I started using Smarty in Nov2003 - and I have been developing my
> class ever since then...
> and it's being successfully used in various projects including a site
> which
> won the people's vote for 'best webshop 2005' in Holland (not really
> as 'big' as it sounds
> - but I'm proud to say I built it, not the graphic design btw!, and
> that Smarty plays no
> small part!)
>
> ---
>
> If any of the core Smarty guys is interested in looking
> at my code I would be prepared to spend a bit of time rolling a zip
> file
> that contains all the relevant files needed to make it work (it forms
> part
> of my custom framework so there quite a few dependencies, some of
> which are
> only relevant to me, which I would have to work thru/check)... php5
> is a
> requirement.
>
> If others want to look, I might consider it too - but really if you
> do want to
> look your php(5) skills will have to be pretty good and you will have
> to want to
> take the time - which is why I offer it to the core/dev guys - I know
> they have the
> skill and that they do research (otherwise they would never have been
> able to write
> such a consistent, solid piece of code!) - regardless if my offer is
> taken up I will
> place the files somewhere everyone who is interested can grab it.
>
> any takers? (I have no config/setup documentation but the code itself
> is quite heavily documented) I'll say up front that I am very willing
> to answer any
> questions that may arise from people who investigate what I have
> done.
>
> (if it's not obvious... I would love to give back a little code to
> the community
> that I have received so much from!)
>
> rgds,
> Jochem.
>
> > outside process needs to co-ordinate that -- and this is the main
> > reason I had been tending towards associating requests with
> actions. I
> > recently submitted a new Addon at the forum and posted at the Wiki
> that
> > I am hoping will help me streamline the process. The main thing
> with
> > this approach is that the plugins you provide must be able to
> > introspect the application to some degree (or at least query
> > application objects) in order to determine state and
> appropriateness.
> > In many cases, I am favouring having the plugins accept a rendering
> > template as a parameter so as to not push the templating directly
> into
> > the plugin code and thereby maintaining the abstraction.
> >
> > I should note that there are pros and cons to both types of
> > associations and I am not trying to suggest that one is better than
> the
> > other. On-the-other-hand, I do try to stick with approaches that
> are
> > flexible and easy to manage and develop. I have found that
> associating
> > requests with actions leads to more developer involvement and tends
> to
> > give less flexibility to designers and trusted template users.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Smarty General Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php