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. > ...
