Thread: [Perl-widget-developer] XSP PerForm taglib (fwd)
Status: Alpha
Brought to you by:
spadkins
From: Matt S. <ma...@se...> - 2001-06-08 21:49:23
|
Thought this might interest some of you widget geeks :-) -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ ---------- Forwarded message ---------- Date: Fri, 8 Jun 2001 22:40:56 +0100 (BST) From: Matt Sergeant <ma...@se...> To: AxKit Users Mailing List <axk...@ax...> Subject: XSP PerForm taglib Taking a bunch of ideas from a number of places I've started putting together what I call the "PerForm" taglib. This is sort of a magic form tag library that will enable you to write web forms sucking data from various sources more easily. I'm looking for some sort of feedback on this, though it's pretty funky as it stands IMHO. Best way to describe it is with an example (this assumes passing familiarity with XSP): =============== <?xml version="1.0"?> <xsp:page xmlns:xsp="http://apache.org/xsp/core/v1" xmlns:web="http://axkit.org/NS/xsp/webutils/v1" xmlns:f="http://axkit.org/NS/xsp/perform/v1" language="perl" indent-result="yes" > <!-- TOP LEVEL LOGIC --> <xsp:logic> # Each function recieves a $ctxt object, which is a hash to # store things in. It has one entry by default, "Form", which # is a hash of form values sub load_title { my ($ctxt, $default, $current) = @_; warn("load_title ($default, $current)\n"); return $current || $default; } sub load_link { my ($ctxt, $default, $current) = @_; warn("load_link ($default, $current)\n"); return $current || $default; } sub save_title { my ($ctxt, $new_value) = @_; warn("save_title : $new_value\n"); } sub save_link { my ($ctxt, $new_value) = @_; warn("save_link : $new_value\n"); } sub start_form_create { my ($ctxt, $save_mode) = @_; warn("start_form\n"); } sub end_form_create { my ($ctxt, $save_mode) = @_; warn("end_form\n"); # if everything is OK, and we're in save_mode, redirect. if ($save_mode) { if ($ctxt->{OK}) { # note mixing taglibs and Perl!!! <web:redirect uri="everything_ok.xsp"/> } } } </xsp:logic> <html> <head> <title>Blah blah</title> </head> <body> <f:form name="create"> Title: <f:textfield type="text" name="title" width="30" maxlength="255" /> <br /> Link: <f:textfield type="text" name="link" width="30" maxlength="255" /> <br /> <!-- I haven't coded the submit button yet! --> <input type="submit"/> </f:form> </body> </html> </xsp:page> =============== OK, hopefully that hasn't confused anyone too much. Now the idea is that these forms always get submitted back to themselves. They do their own validation. If everything went well and the form got saved OK, they issue a redirect to another page. It's kinda like the MVC model, only slightly spiced the AxKit way :-) Now when the form is first loaded, the input fields are populated by a callback to the load_<name>() function, where <name> is the name entry of the particular form field. So to populate the first textfield, it calls load_title(...). It passes in parameters $ctxt, $default, and $current. Note that $current will only be filled if this form has already been submitted once (filled with the current value, obviously). The value you return is what goes in the text box that the user sees. When the form is submitted, the save_<name>() functions are called. This time they are passed the $ctxt and the new value. There you can do validation or whatever you like (save to a DB, etc). Each view of the form is started by a call to start_form_<name>(), where <name> this time is the name attribute on the form. When all the form's callbacks have been performed, the end_form_<name>() callback is called. The $ctxt object is a simple hashref that you can fill with whatever you like. It's there to help you maintain state between the callbacks. It contains one entry by default, "Form", which is a hashref to all the other form values. This allows you to do validation where one value depends on another. If you *don't* want to supply callbacks for load_*, then it defaults to using either the current value (i.e. the value last posted to the form), or the default value specified if this is the first load of this form. Now when all this has been done, it doesn't generate a HTML widget. It just generates some XML decorated with all the relevant attributes. You need to write an XSLT stylesheet (which I'll include with the package for HTML) to render it to HTML. But it's really simple to do that with xsl:include/xsl:import. I may even be persuaded to do an XPathScript stylesheet for it :-) I welcome your feedback on this. I think it will make building complex forms really easy. One nice thing with XML is we can put all that nasty callbacks code in another file, and use entities to load it in. Or we can use "use OtherPackage qw(...)" to import the functions to the current namespace. Either way will work. I can put this in CVS if people want to play with it as it stands. But I have only implemented the textfield widget as yet. -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ --------------------------------------------------------------------- To unsubscribe, e-mail: axk...@ax... For additional commands, e-mail: axk...@ax... |
From: Gunther B. <gu...@ex...> - 2001-06-11 10:02:52
|
My initial reaction is that I think this is much more complex than a widget library that produces HTML and it's even less clear to me that XML is a good delivery mechanism for abstracting forms. I truly believe that when you make an app into an HTML app vs a WML app vs anything else that the screens are significantly different. I think that this XML stuff may be fine for content sites like newspapers, but for an app it seems like it's a lot of work for much less gain than you get on the pure content management side. Later, Gunther At 10:49 PM 6/8/2001 +0100, Matt Sergeant wrote: >Thought this might interest some of you widget geeks :-) > >-- ><Matt/> > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ > >---------- Forwarded message ---------- >Date: Fri, 8 Jun 2001 22:40:56 +0100 (BST) >From: Matt Sergeant <ma...@se...> >To: AxKit Users Mailing List <axk...@ax...> >Subject: XSP PerForm taglib > >Taking a bunch of ideas from a number of places I've started putting >together what I call the "PerForm" taglib. This is sort of a magic form >tag library that will enable you to write web forms sucking data from >various sources more easily. > >I'm looking for some sort of feedback on this, though it's pretty funky as >it stands IMHO. > >Best way to describe it is with an example (this assumes passing >familiarity with XSP): > >=============== > ><?xml version="1.0"?> ><xsp:page > xmlns:xsp="http://apache.org/xsp/core/v1" > xmlns:web="http://axkit.org/NS/xsp/webutils/v1" > xmlns:f="http://axkit.org/NS/xsp/perform/v1" > language="perl" > indent-result="yes" > > ><!-- TOP LEVEL LOGIC --> ><xsp:logic> > ># Each function recieves a $ctxt object, which is a hash to ># store things in. It has one entry by default, "Form", which ># is a hash of form values > >sub load_title { > my ($ctxt, $default, $current) = @_; > warn("load_title ($default, $current)\n"); > return $current || $default; >} > >sub load_link { > my ($ctxt, $default, $current) = @_; > warn("load_link ($default, $current)\n"); > return $current || $default; >} > >sub save_title { > my ($ctxt, $new_value) = @_; > warn("save_title : $new_value\n"); >} > >sub save_link { > my ($ctxt, $new_value) = @_; > warn("save_link : $new_value\n"); >} > >sub start_form_create { > my ($ctxt, $save_mode) = @_; > warn("start_form\n"); >} > >sub end_form_create { > my ($ctxt, $save_mode) = @_; > warn("end_form\n"); > # if everything is OK, and we're in save_mode, redirect. > if ($save_mode) { > if ($ctxt->{OK}) { > # note mixing taglibs and Perl!!! > <web:redirect uri="everything_ok.xsp"/> > } > } >} > ></xsp:logic> > >Title: >Link: ></xsp:page> > >=============== > >OK, hopefully that hasn't confused anyone too much. Now the idea is that >these forms always get submitted back to themselves. They do their own >validation. If everything went well and the form got saved OK, they issue >a redirect to another page. It's kinda like the MVC model, only slightly >spiced the AxKit way :-) > >Now when the form is first loaded, the input fields are populated by a >callback to the load_<name>() function, where <name> is the name entry of >the particular form field. So to populate the first textfield, it calls >load_title(...). It passes in parameters $ctxt, $default, and $current. >Note that $current will only be filled if this form has already been >submitted once (filled with the current value, obviously). The value you >return is what goes in the text box that the user sees. > >When the form is submitted, the save_<name>() functions are called. This >time they are passed the $ctxt and the new value. There you can do >validation or whatever you like (save to a DB, etc). > >Each view of the form is started by a call to start_form_<name>(), where ><name> this time is the name attribute on the form. When all the form's >callbacks have been performed, the end_form_<name>() callback is called. > >The $ctxt object is a simple hashref that you can fill with whatever you >like. It's there to help you maintain state between the callbacks. It >contains one entry by default, "Form", which is a hashref to all the other >form values. This allows you to do validation where one value depends on >another. > >If you *don't* want to supply callbacks for load_*, then it defaults to >using either the current value (i.e. the value last posted to the form), >or the default value specified if this is the first load of this form. > >Now when all this has been done, it doesn't generate a HTML widget. It >just generates some XML decorated with all the relevant attributes. You >need to write an XSLT stylesheet (which I'll include with the package for >HTML) to render it to HTML. But it's really simple to do that with >xsl:include/xsl:import. I may even be persuaded to do an XPathScript >stylesheet for it :-) > >I welcome your feedback on this. I think it will make building complex >forms really easy. One nice thing with XML is we can put all that nasty >callbacks code in another file, and use entities to load it in. Or we can >use "use OtherPackage qw(...)" to import the functions to the current >namespace. Either way will work. > >I can put this in CVS if people want to play with it as it stands. But I >have only implemented the textfield widget as yet. > >-- ><Matt/> > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: axk...@ax... >For additional commands, e-mail: axk...@ax... > > > >_______________________________________________ >Perl-widget-developer mailing list >Per...@li... >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer __________________________________________________ Gunther Birznieks (gun...@eX...) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ |
From: Matt S. <ma...@se...> - 2001-06-11 10:31:20
|
On Mon, 11 Jun 2001, Gunther Birznieks wrote: > My initial reaction is that I think this is much more complex than a widget > library that produces HTML and it's even less clear to me that XML is a > good delivery mechanism for abstracting forms. What XML gains you is parsability, so you can generate code easier when you just stick widgets on the form. > I truly believe that when you make an app into an HTML app vs a WML app vs > anything else that the screens are significantly different. Well that's fair enough, and you can do that too with this system. I believe you totally that WML and HTML forms are significantly different. The idea here though is to allow developers to use the same widget language for different forms. > I think that this XML stuff may be fine for content sites like newspapers, > but for an app it seems like it's a lot of work for much less gain than you > get on the pure content management side. I've changed the implementation a bit since I posted that, though you appear pretty set in stone about your ideas of a good widget system... So given a form as follows: <f:form name="mailinglist> <f:textfield name="email"/> <f:single-select name="type"/> <f:submit name="subscribe" value="Submit"/> <f:submit name="cancel" value="Cancel"/> </f:form> You can optionally (all functions are optional) supply the following subs: start_form_mailinglist end_form_mailinglist load_email validate_email load_type validate_type submit_subscribe submit_cancel I think (hope) the sub names are pretty self explanatory now. Each sub recieves a $ctxt object so you can maintain state. I'm thinking of including the form name in the widget callback subs somehow, so you can have widgets of the same name on the same page but in different forms. The return value of submit_* is a string that the library sends a redirect to. Anyway, this isn't the same goal as your Widget.pm library. You could never use that in AxKit/XSP because its designed very differently from any technology you are used to. So this is a simple way to do forms for people using AxKit, and I think it's a lot easier than the current methods (current methods available in AxKit/XSP, that is). Enjoy :-) -- <Matt/> /|| ** Founder and CTO ** ** http://axkit.com/ ** //|| ** AxKit.com Ltd ** ** XML Application Serving ** // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\ |
From: Jay L. <Ja...@La...> - 2001-06-11 14:14:59
|
I think we can all safely say that XML is an application developer's choice and won't be part of the core Widget development effort - but rather an important side project if people want to use XML to create and control widgets. Agreed? Jay > My initial reaction is that I think this is much more complex than a widget > library that produces HTML and it's even less clear to me that XML is a > good delivery mechanism for abstracting forms. > > I truly believe that when you make an app into an HTML app vs a WML app vs > anything else that the screens are significantly different. > > I think that this XML stuff may be fine for content sites like newspapers, > but for an app it seems like it's a lot of work for much less gain than you > get on the pure content management side. > > Later, > Gunther > > At 10:49 PM 6/8/2001 +0100, Matt Sergeant wrote: > >Thought this might interest some of you widget geeks :-) > > > >-- > ><Matt/> > > > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > > // \\| // ** mod_perl news and resources: http://take23.org ** > > \\// > > //\\ > > // \\ > > > >---------- Forwarded message ---------- > >Date: Fri, 8 Jun 2001 22:40:56 +0100 (BST) > >From: Matt Sergeant <ma...@se...> > >To: AxKit Users Mailing List <axk...@ax...> > >Subject: XSP PerForm taglib > > > >Taking a bunch of ideas from a number of places I've started putting > >together what I call the "PerForm" taglib. This is sort of a magic form > >tag library that will enable you to write web forms sucking data from > >various sources more easily. > > > >I'm looking for some sort of feedback on this, though it's pretty funky as > >it stands IMHO. > > > >Best way to describe it is with an example (this assumes passing > >familiarity with XSP): > > > >=============== > > > ><?xml version="1.0"?> > ><xsp:page > > xmlns:xsp="http://apache.org/xsp/core/v1" > > xmlns:web="http://axkit.org/NS/xsp/webutils/v1" > > xmlns:f="http://axkit.org/NS/xsp/perform/v1" > > language="perl" > > indent-result="yes" > > > > ><!-- TOP LEVEL LOGIC --> > ><xsp:logic> > > > ># Each function recieves a $ctxt object, which is a hash to > ># store things in. It has one entry by default, "Form", which > ># is a hash of form values > > > >sub load_title { > > my ($ctxt, $default, $current) = @_; > > warn("load_title ($default, $current)\n"); > > return $current || $default; > >} > > > >sub load_link { > > my ($ctxt, $default, $current) = @_; > > warn("load_link ($default, $current)\n"); > > return $current || $default; > >} > > > >sub save_title { > > my ($ctxt, $new_value) = @_; > > warn("save_title : $new_value\n"); > >} > > > >sub save_link { > > my ($ctxt, $new_value) = @_; > > warn("save_link : $new_value\n"); > >} > > > >sub start_form_create { > > my ($ctxt, $save_mode) = @_; > > warn("start_form\n"); > >} > > > >sub end_form_create { > > my ($ctxt, $save_mode) = @_; > > warn("end_form\n"); > > # if everything is OK, and we're in save_mode, redirect. > > if ($save_mode) { > > if ($ctxt->{OK}) { > > # note mixing taglibs and Perl!!! > > <web:redirect uri="everything_ok.xsp"/> > > } > > } > >} > > > ></xsp:logic> > > > >Title: > >Link: > ></xsp:page> > > > >=============== > > > >OK, hopefully that hasn't confused anyone too much. Now the idea is that > >these forms always get submitted back to themselves. They do their own > >validation. If everything went well and the form got saved OK, they issue > >a redirect to another page. It's kinda like the MVC model, only slightly > >spiced the AxKit way :-) > > > >Now when the form is first loaded, the input fields are populated by a > >callback to the load_<name>() function, where <name> is the name entry of > >the particular form field. So to populate the first textfield, it calls > >load_title(...). It passes in parameters $ctxt, $default, and $current. > >Note that $current will only be filled if this form has already been > >submitted once (filled with the current value, obviously). The value you > >return is what goes in the text box that the user sees. > > > >When the form is submitted, the save_<name>() functions are called. This > >time they are passed the $ctxt and the new value. There you can do > >validation or whatever you like (save to a DB, etc). > > > >Each view of the form is started by a call to start_form_<name>(), where > ><name> this time is the name attribute on the form. When all the form's > >callbacks have been performed, the end_form_<name>() callback is called. > > > >The $ctxt object is a simple hashref that you can fill with whatever you > >like. It's there to help you maintain state between the callbacks. It > >contains one entry by default, "Form", which is a hashref to all the other > >form values. This allows you to do validation where one value depends on > >another. > > > >If you *don't* want to supply callbacks for load_*, then it defaults to > >using either the current value (i.e. the value last posted to the form), > >or the default value specified if this is the first load of this form. > > > >Now when all this has been done, it doesn't generate a HTML widget. It > >just generates some XML decorated with all the relevant attributes. You > >need to write an XSLT stylesheet (which I'll include with the package for > >HTML) to render it to HTML. But it's really simple to do that with > >xsl:include/xsl:import. I may even be persuaded to do an XPathScript > >stylesheet for it :-) > > > >I welcome your feedback on this. I think it will make building complex > >forms really easy. One nice thing with XML is we can put all that nasty > >callbacks code in another file, and use entities to load it in. Or we can > >use "use OtherPackage qw(...)" to import the functions to the current > >namespace. Either way will work. > > > >I can put this in CVS if people want to play with it as it stands. But I > >have only implemented the textfield widget as yet. > > > >-- > ><Matt/> > > > > /|| ** Founder and CTO ** ** http://axkit.com/ ** > > //|| ** AxKit.com Ltd ** ** XML Application Serving ** > > // || ** http://axkit.org ** ** XSLT, XPathScript, XSP ** > > // \\| // ** mod_perl news and resources: http://take23.org ** > > \\// > > //\\ > > // \\ > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: axk...@ax... > >For additional commands, e-mail: axk...@ax... > > > > > > > >_______________________________________________ > >Perl-widget-developer mailing list > >Per...@li... > >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer > > __________________________________________________ > Gunther Birznieks (gun...@eX...) > eXtropia - The Open Web Technology Company > http://www.eXtropia.com/ > > > _______________________________________________ > Perl-widget-developer mailing list > Per...@li... > http://lists.sourceforge.net/lists/listinfo/perl-widget-developer > |
From: Stephen A. <ste...@of...> - 2001-06-12 11:25:24
|
At 10:16 AM 6/11/2001 -0400, you wrote: >I think we can all safely say that XML is an application developer's choice >and won't be part of the core Widget development effort - but rather an >important >side project if people want to use XML to create and control widgets. > >Agreed? > >Jay XML in the usage that Matt mentions belongs more in the AxKit realm. The Widget approach is a different approach. However, I am using XML as a configuration file format. It will not be the default configuration file format (changing over to native perl at the list's request), but it will be a standard option. Stephen |