Gunther,

I consulted the mod_perl list

   http://perl.apache.org/#maillists

and read the thread in question

   http://forum.swarthmore.edu/epigone/modperl/yandyphor

I agree this is more a general purpose Perl module
which would also be useful in templates created for the Template Toolkit.
I am very interested in developing this, as I have already put a
good bit of thought and effort into something which sounds like
what you are getting at.

Please do not reply on this list.
I will post a message to the mod_perl list, and we can continue
the conversation there.
I will bring this topic back to this list when there is enough in
place and I might need a little help writing the TT plugin code.

Stephen

At 08:28 PM 5/23/2001 +0800, Gunther Birznieks wrote:
>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/
>
>
>_______________________________________________
>templates mailing list
>[EMAIL PROTECTED]
>http://www.template-toolkit.org/mailman/listinfo/templates
>



Reply via email to