I don't know if this will bounce me because I am not a member of the
template-toolkit list.
However...
The reason I posted my own requirements on mod_perl list rather than here
in the end was because I believe such a library can be written
independently of TT. Of course, our first cut (because we use TT for
eXtropia apps) we'd want a plugin to make it work as a TT tag.
The thing is, what I want to do exists partially in Struts Java framework
project and already in our Java toolkit (for JSP Model-View-Controller)
stuff that we do. And I know that model works and it works well because
it's such a joy for me when I use that part of Java for the last 6 months.
Of course, everything else sucks like the debugging cycle that Java makes
me go through.
But I want to bring this particular model back to Perl and what we do there.
Anyway, I felt I would get better response on the mod_perl list because
many template authors hang out there and this should interest them
all. But I am open to suggestions. I have posted the basic API and object
hierarchy that I would expect (loosely) this to be made up of on there. But
if you think it's best to cross post, then I could do that too.
Thanks,
Gunther
At 08:22 AM 5/23/01 -0400, Stephen Adkins wrote:
>Hi,
>
>I am working on something that sounds similar.
>I would like to work on it.
>How do I get to the center of this discussion and catch up on what has been
>discussed about it?
>Is it the mod_perl list or this list or what?
>
>Stephen
>
>At 02:48 PM 5/23/2001 +0800, Stas Bekman wrote:
>...
> >But this only talks about simple rendering. But take for example something
> >like a date widget. When introduced in the <FORM> we want the date widget
> >to appear as [YEAR][MONTH][DAY] (3 elements), whereas for usual user
> >display mode it should automatically know to render itself as %d-%M-%Y
> >strftime string and similar. We are talking about "inteligent" widgets,
> >doing different things in different contexts.
> >
> >I suppose it might be a mistake to try to provide TT-specific widget
> >library, and it should be a more abstract thing with glues to various
> >backends (TT/CGI/...) and frontends (CGI/Apache::Request/...).
> >
> >Gunther has started this thread on the mod_perl list, it seems that such a
> >beast doesn't exist in Perl domain, and there are people willing to give
> >hand, but so far nobody has offered to start a new Perl project and lead
> >the effort. Hmm, may be someone on this list needs the same kind of
> >functionality and have the interest/resources to start the project to
> >implement smart widgets in Perl.
> >
> >> > So I was thinking that some sort of collaboration between
> Apache::Request
> >> > (or even CGI.pm for mod_cgi) and TT would be extremely useful, where the
> >> > the former playes the role of handling incoming GET/POST data,
> handing it
> >> > to TT transparently to the user (like CGI.pm does) and the latter knows
> >> > how to render the final HTML/other widget(s), and probably knows about
> >> > stickyness of data.
> >>
> >> Yes, I like the idea. Maybe this could be implemented at the Service
> >> level? For example, subclass Template::Service to Template::Service::HTTP
> >> to add the HTTP GET/POST methods. The existing Template::Service::Apache
> >> module (part of Apache::Template) could then be derived from that. We
> >> would probably want a Template::CGI module which automatically selects
> >> the HTTP SERVICE object, but otherwise acts just like Template. This
> would
> >> allow people to write their CGI scripts as:
> >>
> >> use Template::CGI;
> >> $tt = Template::CGI->new( ... );
> >>
> >> At the start of the template request, the service could either (depending
> >> on configuration) examine the HTTP headers and pre-parse them, storing the
> >> results in the stash somewhere, or install callbacks or other references
> >> into the stash for users and/or plugins to utilise as they require.
> >>
> >> The HTTP plugin could then be an interface back to the request (via the
> >> service callbacks) through which templates could examine headers, set
> >> cookies, etc.
> >
> >Whoah, this means that just like with DBI plugin you can write simple cgis
> >with almost no perl side code to interact with DB, you will be able to
> >write simple cgi scripts with no perl code at all :)
> >
> >> Sounds good. Who wants to write it? :-)
> >
> >I'd definitely do that if... I won't need to port our old ADT HTML-in-Perl
> >implementation to use TT and separate views from the code on the way.
> >
> >This looks like a great project to learn TT guts, so probably somebody on
> >this list will be glad to jump on this challenging problem, implement it
> >and enjoy the gratitude of fellow perl/tt coders.
> >
>
>...
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
