|
|
Posted by Jochem Maas on 08/05/05 04:09
right then, I finally got my ass in gear a bit and pulled together the
files that make up my Smarty 'extension'. hopefully all required files
are included (bit hard to tell because of the way my whole framework
is quite tightly integrated) - I changed the require_once() statements
so that all the classes can live in one dir - should be okay.
if you seem to be missing files (undefined funcs or what have), need help getting
it to run, have any kind of questions etc etc etc then I'm at your service.
(it will take a little effort to get it up and running - but you [boots]
don't seem like the kind of guy who minds a bit of a challenge!
here is the link: http://iamjochem.com/SmartyPage.zip
(as I was writing this I realised I missed out a couple of plugins -
so I went back and included a whole bunch to be on the safe side - please note
that many of these plugins are customized ['enhanced'?] versions of
std. plugins - you may find them interesting but then again they may just get
in your way, at any rate I have always tried to make all the changes to std.
plugins in such a way as not to affect the original behaviour if you don't use
the extra stuff I added). I also added a limited directory structure so that
you might get an idea as to the layout I used ('my' smarty plugins can be found
in a couple of the subdirs)
WARNING: the way I setup/define $Smarty->plugins_dir and $Smarty->template_dir
may be totally not what you want - same goes for templates_c, config (which I have
never used) and cache dir - in which case change the code at lines 145-165 in
SmartyPage.class.php.
look forward to hearing from you or anyone else for that matter ;-)
btw - I read your comments about __get()/__set() on internals with interest :-),
not sure that I would like to see _any_ changes there - I'd rather see the new unicode
and date related stuff come to fruition first :-)
rgds,
Jochem
boots wrote:
> 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 <jochem@iamjochem.com> 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
>
Navigation:
[Reply to this message]
|