You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Gunther Birznieks <gu...@extropia.com> on 2001/05/22 10:13:23 UTC
Real Widgets and Template Languages
There has been some discussion on the list lately about generating widgets
ala CGI.pm, HTML::StickyWidgets etc...
The thing is that these products or plug-ins are very HTML oriented. The
widget is defined as an HTML widget like a textfield or checkbox or
dropdown or what-have-you.
What I am really looking for is a library that abstracts and allows widgets
to be developed that are tied to an application not to a set of HTML
necessarily. I guess I will start by providing an example of what I want
based on what we currently do in our Java framework when he use Templating
there. I'd like it if someone has developed the same thing in Perl that we
could reuse, otherwise, we may need to write this.
A widget should be a plugin or tag that may be embedded in a template with
the definition of that widget tied to some APPLICATION-LEVEL piece of data
entry not at the HTML-LEVEL.
For example,
<TR>
<TH>First Name:</TH><TD><widget id="fname"/></TD>
<TH>Last Name:</TH><TD><widget id="lname"/></TD>
<TH>Comments</TH><TD><widget id="comments"/></TD>
</TR>
As you can see the basic idea is that the <widget> tag (or it could be Perl
object embedded in the template) is actually *intelligent*.
It should be configured as a Perl object that knows that an fname is a
textfield and an lname is a textfield and a comments field is a text area.
And if I change my mind and decide that comments is better off as a
textfield, I should not have to change any templates that use the <widget
id="comments"/> tag.
Now, HTML::StickyWidgets and CGI.pm could be used by a true widget
abstraction library to generate HTML widgets. But what I want to do is
provide the capability of also abstracting even higher. Like at the data level.
I forsee a
WidgetCollection class which holds widgets together
Widget class that provides the interface to what a widget does
and Widget::XXXX subclasses that provide definitions relevant to the widget
types used on the forms.
Where HTML::StickyForms comes in is something like
Widget::HTML::TextField
Widget::HTML::TextArea
Widget::HTML::CheckBox
etc...
This is extensible as we provide more cross platforms ones can be added as
Widget::WML::TextField
Widget::WML::CheckBox
And it support intelligence...
Widget::HTML::Date is a widget that would actually contain a drop down for
month, a drop down for day and a drop down for year parts of a Date.
But the widget object itself can set and get it's data as a Date string.
In other words, the nice thing about a generic Widget library is that you
can start easy (aka HTML::StickyWidgets) but you can end up with a library
of common tags that many applications require.
I believe such a library of widget plug-ins could be made semi-indepenent
of the templating language used with perhaps plugin wrappers for each one
(In particular I am interested in TemplateToolkit).
The way these widgets would be configured is something like the following
my $widget_collection = new WidgetCollection(
-WIDGET_FORM_DATA => $CGI , # (CGI.pm object)
-WIDGET_HASH =>
'fname' => new Widget(-TYPE => HTML::TextField, -NAME=> "fname"....)
'lname' => new Widget(-TYPE => HTML::TextField, -NAME=> 'lname'....),
'birthday' => new Widget(-TYPE => HTML::Date, -DAY_NAME => "dob_day"....)
)
Then if I want to get a widget...I can say
my $widget = $widget_collection->getWidget('fname');
By default the widget object data is set using the CGI.pm object (or
Apache::Request)
But you can manually get and set the data...
print $widget->get_value();
or
$widget->set_value("gunther");
In the case of a date widget... you can do something like
$widget->set_value("5/22/2001"); if the format defined in the constructor
of the date widget was "5/22/2001" for mm/dd/yyyy
And most importantly, widgets know how to display themselves...
print $fname_widget->display(); prints the HTML text field
whereas
print $date_of_birth_widget->display(); prints the three drop downs that
represents the month day and year.
Of course, the widget library could be expanded by the open source
community. For example, I can imagine a date widget that also has a button
that says "Click for Calendar"... and then a javascript popup comes up with
a mini-calendar for selecting the date.
Does anyone have a widget framework like this? I think the closest I found
to widget abstraction is SmartWorker, but it is not abstract in quite the
way that I want above.
What I want is a business or application context widget that can be
configured on-the-fly to be something other than a plain HTML widget. After
using this concept in our Java toolkit for 6 months, I find the abstraction
to be quite useful and really want to have the same feature in Perl.
Has someone done this already?
Thanks,
Gunther
Re: Real Widgets and Template Languages
Posted by Adi Fairbank <ad...@certsite.com>.
Gunther,
I have been interested in the concept of an HTML widget module for a while
now. The reason being, my application currently generates all HTML using
CGI.pm in a mod_perl handler OO-style design, and we are starting to notice
patterns.. similar pieces of HTML that get generated over and over.
Needless to say, componentized, reusable widgets would be very useful for
us.
Though I can't make the commitment of writing it myself (if I did, it would
be about 6 months before you saw any code), I would definitely contribute to
it, if it existed. And like you said, the hard part is getting people to
write the widget objects.
-Adi
Re: Real Widgets and Template Languages
Posted by Gunther Birznieks <gu...@extropia.com>.
At 02:26 PM 5/22/2001 -0400, kyle dawkins wrote:
>On Tue, 22 May 2001 06:25, Matt Sergeant wrote:
> > On Tue, 22 May 2001, Gunther Birznieks wrote:
> > > I want/need a *Perl* solution!
> >
> > Well if you can pay for it... (still unemployed here and getting poorer
> > waiting for people to possibly say yay or nay on possible contracts...)
>
>Ummm... you guys could look at
>
>http://www.smartworker.org
Ummm... you could also read my first post on the subject which already
mentioned smartworker. Smartworker isn't what we need to accomplish what I
am talking about.
Smartworker has a great UI framework but it is a UI framework. It does not
operate at the level of application logic which is the level I wish to have
widgets operate under.
I realize this is a difficult concept to both explain and understand.
Hopefully the rest of my post will put it in a different nutshell.
>And if that's not your cup of tea, I should be releasing something sometime
>in the fairly near future that will be.
I am not sure. It would be great if that was the case!
Could you describe in a few sentences what you will be releasing? I don't
think you precisely understood what I was asking for or read my entire post
if you just forwarded me to smartworker again, so I hope you forgive my
skepticism. As mentioned, if what you can provide does what I want, then
that would be great.
What I don't want: Another HTML Widget library or another UI library
What I do want: A way of logically specifying an application-based widget
(eg post something saying <widget id='fname'> that is intelligent enough to
know how to render itself based on an application config.
Re: Real Widgets and Template Languages
Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 22 May 2001, Gunther Birznieks wrote:
> > > Has someone done this already?
> >
> >Struts. But you knew that already :-)
>
> For those that do not know struts is a Java framework and I think someone
> is trying to get me riled up!
>
> I want/need a *Perl* solution!
Well if you can pay for it... (still unemployed here and getting poorer
waiting for people to possibly say yay or nay on possible contracts...)
--
<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 **
\\//
//\\
// \\
Re: Real Widgets and Template Languages
Posted by Gunther Birznieks <gu...@extropia.com>.
At 10:13 AM 5/22/2001 +0100, Matt Sergeant wrote:
>On Tue, 22 May 2001, Gunther Birznieks wrote:
>
> > Does anyone have a widget framework like this? I think the closest I found
> > to widget abstraction is SmartWorker, but it is not abstract in quite the
> > way that I want above.
>
>We're planning to do something like this as a taglib in XSP for AxKit.
>It's quite a big task though, as we want widgets to also be intelligent in
>the way they are mapped to forms processing code.
I think it is a big task. On the other hand, in thinking about it, I think
the actual logic behind widgets could be fairly simple. The hard part is
getting people to write the various widget objects. Again, I think all the
various HTML widgets could use an underlying library like HTML::StickyWidgets.
And then the remaining hard part is writing the template language wrappers
that actually allow them to be embedded in pages as tags where it is XSP
tags for AxKit or plugins for TemplateToolkit.
> > Has someone done this already?
>
>Struts. But you knew that already :-)
For those that do not know struts is a Java framework and I think someone
is trying to get me riled up!
I want/need a *Perl* solution!
:)
Re: Real Widgets and Template Languages
Posted by Gunther Birznieks <gu...@extropia.com>.
At 04:21 PM 5/31/01 -0700, brian moseley wrote:
>On Thu, 31 May 2001, Gunther Birznieks wrote:
>
> > Let's put it this way, I have actually used widgets for
> > the last 6 months in real world applications using JSPs
> > and widget libraries in Java. I can't tell you what a
> > joy it is to work with something so relatively simple
> > and just easy to put things in a page.
>
>which widget libraries?
Our own. But I understand Struts apache project has the same basic deal (as
also confirmed by Matt Sergeant's post). And from looking at Struts I think
their model is even simpler than the model we have in our Java toolkit.
This is why I am quite frightened of all these additions to a widget API in
Perl when I know it's been accomplished so simply as a framework in Java.
__________________________________________________
Gunther Birznieks (gunther.birznieks@eXtropia.com)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Real Widgets and Template Languages
Posted by brian moseley <bc...@maz.org>.
On Thu, 31 May 2001, Gunther Birznieks wrote:
> Let's put it this way, I have actually used widgets for
> the last 6 months in real world applications using JSPs
> and widget libraries in Java. I can't tell you what a
> joy it is to work with something so relatively simple
> and just easy to put things in a page.
which widget libraries?
Re: Real Widgets and Template Languages
Posted by Gunther Birznieks <gu...@extropia.com>.
At 05:52 PM 5/28/01 -0400, you wrote:
> > Let's focus a bit.
> Specifically on requirements more than implementation - *GOOD*
I think you misread my intention. I think the requirements are simple and
fairly clear except for some interesting enhancements people (includign
yourself) propose on the list. I'd like to get a set of objects out more
quickly that only do a few things well and in a small lightweight interface.
>Could I paraphrase or reinterpret what you have said to be base classes
>for handling widget properties and data sources?
>
>In the web world I see data coming from:
> static widget properties - design/configuration values
> user supplied values - Session and Request values
> data sources - RDBMS, LDAP, yadda
>
>In addition I do see a variety of flavours for this data: scalar, array,
>hash. Me, I want even more exotic flavours such as language sensitive (The
>lable property check's user's language choice and will give them back the
>lable in the right language). In order for a widget set to be useful we have
>to agree on how to pass around a certain set of potentially complex data
>types.
>
>READ: robust base object class with potentially fancy strategy for
>rationalizing a number of data sources and data structures.
This is very vague to me. It just doesn't sound very concrete enough. I
think an interface to be able to do reference to a hash where values are
either ref to an array or scalar is good enough initially.
>Additionally - when it comes to widget-specific actions - such as rendering,
>then you're seeing this as a subclass (or group of methods) that has been
>defined by the widget creator.
> ie/ widget->render - generic method that checks container and calls
>appropriate render subclass for this widget
> since container is HTML return widget->render_HTML or whatever.
I think breaking out render subwidgets is too complex for my tastes.
>READ: object hierarchy. Objects check their parents for hints on how to do
>things - like pick the form to render themselves, etc.
>
> > 1. Data Validation logic. No, this does not belong there. This is a
> > separate library. I already have a rich Data handling library in my
>toolkit
> > that I intend to plug widgets into. All I need is to be able to get widget
> > data from the data handling/validation library.
>
>If I place a widget into my user interface and allow a user to specify a
>value how I am I to implement validation?
>
>ie/ Widget has property "choice" which can be "1","2", or "3". If the user
>supplies any other value I want choice to be NULL and raise an error.
>
> A - does controlling application logic enforce choice validation
> B - does widget have property information to say that choice property
>must pass some validation process?
>
>I like B because it further compartmentalizes the behaviors of the widget
>within its own specification. The source of the valication routines can be
>external to the widget and classes but the validation rules would be
>specified within here.
This is exactly why config should not be part of the widget library except
as a side optional item. You can make your config also optionally configure
data handling rules, but mine might not. Then its up to your app toolkit
(if it wants to) to set up the data handler methods to be called when the
form is submitted to the CGI based on that config.
> > 2. External display stuff. No, I just want the widget to know how to draw
> > itself and only itself. It's up to a template language plugin like TT or
> > some other template language to provide the wrappings. Or it can be a
> > toolkit like your drawing forms library -- but the widget itself shouldn't
> > have to know about external decoration around it. Just how to draw itself.
>
>If one is to create an HTML form on a web page then all of the form elements
>should actually be contained within in a FORM container. The FORM container
>can then facillitate the correct development of HTML etc.
>
>If the widgets are used within another context then the FORM container might
>be necessary or it might not. But it is usually easier to ignore than try to
>backpeddle and whack stuff in after its kinda too late.
It's pretty rare for this to be an issue. If it is, I would rather see a
form become a widget that is linked to another widget if you really require
functionality like this.
> > It's possible, but I am not quite sure because the primary complexity
>seems
> > to be the data handling (which I have already in a separate abstraction)
> > and the UI generation which I have already in Template Toolkit. So all I
> > really want is an object abstract called a Widget along with a
> > WidgetCollection to allow grouping widgets together that belong on a given
> > HTML page.
>
>The way I am seeing a solution come together is somewhat different. First of
>all I am now tending to really really really want to work with persistant
>object collections. As my application needs new widgets I instanciate a new
>object of that class into the app's collection of objects. Then I can set
>its properties as I wish. From that point onwards I can just boss the
>widgets around and make 'em do what I want.
>
>If you do not want to work with persistent object system then you can come
>up with any number of tactics to define your widget objects as needed: XML,
>inline code, Data::Dumper, etc.
>
>A few of my thoughts,
I think your thoughts are interesting but way too complex for my own
interests. The stuff that you describe that's complex is also described
anecdotally. I really shudder to think what would happen when it is really
coded and when it is really put in practice. I just would hate to have a
really complex library that takes people a long time to grasp and
understand because it is hyper broken out.
Let's put it this way, I have actually used widgets for the last 6 months
in real world applications using JSPs and widget libraries in Java. I can't
tell you what a joy it is to work with something so relatively simple and
just easy to put things in a page.
And Java is known for being overdesigned and complex. :)
So I guess I am really against bloating the feature set and the API of
something that should be relatively simple and that I could enjoy if it
actually comes together in a couple weeks instead of being something where
I have to have a Visio to understand the hierarchy at all.
What I am NOT against is you stating what would be cool. So I think that is
useful. I am not intending to be disparaging.
But I am against implementing all these features right away so there's
gotta be some choice. And I really do think that some of the warnings about
thinking things through are not really warranted because I have been
working with this stuff on another platform. I just want Perl to enjoy the
same feature. There is some room for adding a few more fancy features, but
I do not believe everything in this mail can be accomplished.
One other thing. For me, this must work on mod_cgi. And if it's going to
cause long load times because the hierarchy is complex and there's a ton of
interfaces to do everything then that will make me unhappy. I am willing to
slow down a bit for mod_cgi in adding a widget feature, but not a lot.
Definitely should not be the equivalent of loading a second copy of CGI.pm
for a normal app.
Re: Real Widgets and Template Languages
Posted by Jay Lawrence <Ja...@Lawrence.Net>.
> Let's focus a bit.
Specifically on requirements more than implementation - *GOOD*
> All I (just my opinion) really want is a widget library for is to get and
> set data in a widget and have the widget subclass know how to display
> itself. In addition, there should be some mechanism for specifying how the
> widget sets up it's internal state based on CGI.pm, Apache::Request,
> Session data or what have you.
Could I paraphrase or reinterpret what you have said to be base classes
for handling widget properties and data sources?
In the web world I see data coming from:
static widget properties - design/configuration values
user supplied values - Session and Request values
data sources - RDBMS, LDAP, yadda
In addition I do see a variety of flavours for this data: scalar, array,
hash. Me, I want even more exotic flavours such as language sensitive (The
lable property check's user's language choice and will give them back the
lable in the right language). In order for a widget set to be useful we have
to agree on how to pass around a certain set of potentially complex data
types.
READ: robust base object class with potentially fancy strategy for
rationalizing a number of data sources and data structures.
Additionally - when it comes to widget-specific actions - such as rendering,
then you're seeing this as a subclass (or group of methods) that has been
defined by the widget creator.
ie/ widget->render - generic method that checks container and calls
appropriate render subclass for this widget
since container is HTML return widget->render_HTML or whatever.
READ: object hierarchy. Objects check their parents for hints on how to do
things - like pick the form to render themselves, etc.
> 1. Data Validation logic. No, this does not belong there. This is a
> separate library. I already have a rich Data handling library in my
toolkit
> that I intend to plug widgets into. All I need is to be able to get widget
> data from the data handling/validation library.
If I place a widget into my user interface and allow a user to specify a
value how I am I to implement validation?
ie/ Widget has property "choice" which can be "1","2", or "3". If the user
supplies any other value I want choice to be NULL and raise an error.
A - does controlling application logic enforce choice validation
B - does widget have property information to say that choice property
must pass some validation process?
I like B because it further compartmentalizes the behaviors of the widget
within its own specification. The source of the valication routines can be
external to the widget and classes but the validation rules would be
specified within here.
> 2. External display stuff. No, I just want the widget to know how to draw
> itself and only itself. It's up to a template language plugin like TT or
> some other template language to provide the wrappings. Or it can be a
> toolkit like your drawing forms library -- but the widget itself shouldn't
> have to know about external decoration around it. Just how to draw itself.
If one is to create an HTML form on a web page then all of the form elements
should actually be contained within in a FORM container. The FORM container
can then facillitate the correct development of HTML etc.
If the widgets are used within another context then the FORM container might
be necessary or it might not. But it is usually easier to ignore than try to
backpeddle and whack stuff in after its kinda too late.
> It's possible, but I am not quite sure because the primary complexity
seems
> to be the data handling (which I have already in a separate abstraction)
> and the UI generation which I have already in Template Toolkit. So all I
> really want is an object abstract called a Widget along with a
> WidgetCollection to allow grouping widgets together that belong on a given
> HTML page.
The way I am seeing a solution come together is somewhat different. First of
all I am now tending to really really really want to work with persistant
object collections. As my application needs new widgets I instanciate a new
object of that class into the app's collection of objects. Then I can set
its properties as I wish. From that point onwards I can just boss the
widgets around and make 'em do what I want.
If you do not want to work with persistent object system then you can come
up with any number of tactics to define your widget objects as needed: XML,
inline code, Data::Dumper, etc.
A few of my thoughts,
Jay
RE: Real Widgets and Template Languages [resend]
Posted by Gunther Birznieks <gu...@extropia.com>.
I read this post a few times.
At 03:44 PM 5/24/01 -0400, David Harris wrote:
>[[ This is a resend.. did some cutting and pasting of code into telnet
>windows that messed it up through shell expansion. My bad. ]]
>
>I have a couple modules that might be the start of what you are calling a
>Widget system. I'm not sure if my modules are in line with the thoughts
>expressed on this list. Pardon me if this is something different: I've been
>loosely following this discussion..
>
>Using my library, whenever I want a form I specify in one list all of the
>elements along with the type of data and any validation routines. Some
>information about how the form should look is also included. My code then
>automatically generates the form (it looks like a dialogue box) from this
>information. The same informational hash is used to parse the form and
>validate the data. If the data is not validated correctly, the form is shown
>again with the validation errors and the data remaining sticky. If the data
>is validated then it is returned in a hash.
I think this is reasonable and correct direction and its good that you've
functionally broken the pieces down.
But the syntax feels like you are wrapping up too many things at once.
We don't really want to define any HTML for the individual widgets. Nor
should the widgets know how to validate themselves. Nor should the widgets
know how to draw stuff around themselves like tables.
>Here is a simplified example of the widget definitions for a form that
>allows a customer to charge money on their credit card into their balance:
>
>[
> amount => { width => "20", same_line => 1,
> label => "Amount to charge (in dollars)", _label => "Amount to
>charge",
> _looks_like => "number", _required => 1, },
>
> [{ addl_require => [{
> type => "sub",
> fields => [qw(amount)],
> sub => sub {
> my ($require, $values, $labels) = @_;
> return "You may not initiate a charge for less than \$5.00."
> if ( $values->[0] < 5 );
> return "You may not initiate a charge for more than \$900.00. If
>you really do want to
> charge this much, then you need to call us and we can do it
>for you."
> if ( $values->[0] > 900 );
> return undef;
> },
> }], }],
>]
"Simplified". :)
Well, while I think this is interesting, it is too much for a widget
library. I think this is fairly clear from the examples.
Let's focus a bit.
All I (just my opinion) really want is a widget library for is to get and
set data in a widget and have the widget subclass know how to display
itself. In addition, there should be some mechanism for specifying how the
widget sets up it's internal state based on CGI.pm, Apache::Request,
Session data or what have you.
1. Data Validation logic. No, this does not belong there. This is a
separate library. I already have a rich Data handling library in my toolkit
that I intend to plug widgets into. All I need is to be able to get widget
data from the data handling/validation library.
2. External display stuff. No, I just want the widget to know how to draw
itself and only itself. It's up to a template language plugin like TT or
some other template language to provide the wrappings. Or it can be a
toolkit like your drawing forms library -- but the widget itself shouldn't
have to know about external decoration around it. Just how to draw itself.
>This above code is showing the strains of evolution of my system. :-) Notice
I don't think it is a strain on the evolution, just that you attempt to
combine many different concepts together. I think it's too much. You can
abstract away some of these things as noted above.
>This really calls for the widgets to be embedded directly in the HTML
>template which contains the formatting a la <widget name=card_name> that
>Gunther proposed.
Yes, but the widgets I propose could also go into a form builder functions
like the ones you laid out as well. The widgets are supposed to be flexible
to suit any template needs not just TT.
>This above code actually sits in a subroutine that returns a list of the
>definitional information. This list is then simply included other places so
>I can write stuff like this:
>
>[
> [qq[
> Enter your billing information and credit card.<p>
> ]],
>
> [qq[ <b>Billing information</b><p> ]],
>
> [{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
>
> CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
>"Billing"),
> undef,
>
> [qq[ <b>Credit card information</b><p> ]],
>
> [{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
>
> CUST::InterfaceUtil::credit_card_fields(),
> undef,
>]
>
>It's great for reuse.
>
>The default_by_name does something interesting: it imports all the defaults
>for the fields (_looks_like and _required and _size) information from the
>database table. If I change the size of a text field in a table all the
>forms which use that text field are automatically updated. (However, I
>should change the default_by_name system so that it doesn't need to be
>specified when I'm including default confirmation. Like I said, this system
>is straining under the evolution.)
This may be interesting, but I still see this as being too much. It looks
more like you have a mini-templating system which is really a language for
drawing GUIs but you are also adding extra stuff like the data validation
on top of it in the same config.
But I think that config can be broken out so that it would make your GUI
drawing library much easier to see.
>I can contribute this library if it would help. I'll warn you that there's
>not too much documentation. I can also contribute some examples of my code
>that use the library.
It's possible, but I am not quite sure because the primary complexity seems
to be the data handling (which I have already in a separate abstraction)
and the UI generation which I have already in Template Toolkit. So all I
really want is an object abstract called a Widget along with a
WidgetCollection to allow grouping widgets together that belong on a given
HTML page.
So on a personal level, I would say this library is not compelling for what
I would like the end-product to be. But others may feel differently.
Re: Real Widgets and Template Languages
Posted by Cees Hek <ce...@sitesuite.net>.
On Wed, 23 May 2001, Gunther Birznieks wrote:
> Hmmm. I had not thought of this because we do not provide this capability
> now in the Java widget library that we have and we don't really miss it.
>
> For color, most UI widgets do not have color. For font and height, I think
> that most designers don't change this often and if they do, it can be
> adjusted in the config file ... usually the widgets themselves don't change
> -- it's the stuff around the forms that do 90% of the time.
I guess what I am really thinking about is things like JavaScript Events.
The widget would be able to automatically add an onChange JS function to
do client side validation of data. But a designer might want to add an
onMouseOver to a widget that will display a layer with a hint describing
how that field should be filled in.
You could just add support for MouseOver Hints to the widget library, but
I could probably come up with a bunch of other things a designer might
want to change on a widget to get it to do, and look how they want.
Cees
Re: Real Widgets and Template Languages
Posted by Gunther Birznieks <gu...@extropia.com>.
At 08:54 PM 5/23/2001 +1000, Cees Hek wrote:
>On Tue, 22 May 2001, Gunther Birznieks wrote:
>
>
>This sounds very useful and powerful. I've been looking for a project to
>help out with, and this one sounds interesting to me. Let me know if you
>want some help developing it, or someone to bounce ideas off...
Yes!
> > <TR>
> > <TH>First Name:</TH><TD><widget id="fname"/></TD>
> > <TH>Last Name:</TH><TD><widget id="lname"/></TD>
> > <TH>Comments</TH><TD><widget id="comments"/></TD>
> > </TR>
>
>One thing that I think is very important is to let designers have control
>over the look and feel of the interface. Your widget library should have
>some mechanism to allow a template designer to specify attributes for a
>widget (like width, height, colour, etc...).
>
><widget id="comments" width="100" height="5" color="red">
>- or -
><widget id="comments" attr="width=100; height=5; color=red">
>
>You can still allow programmers to have control over how the data is
>verified, and other attributed like maxlength for text fields and
>such.
>
>Of course these attributes will not be useful in every type of widget.
>ie if the programmer decided that this widget is going to be a text field
>instead of a textarea, then the above height attribute would be useless,
>and ignored.
Hmmm. I had not thought of this because we do not provide this capability
now in the Java widget library that we have and we don't really miss it.
For color, most UI widgets do not have color. For font and height, I think
that most designers don't change this often and if they do, it can be
adjusted in the config file ... usually the widgets themselves don't change
-- it's the stuff around the forms that do 90% of the time.
However, it does bring up an interesting point. On the one hand, I want to
abstract away from the designer what the widget is. For example, it should
be up to the app developer whether I use a textfield or a text area. But
defining a "width" for a text area is very different from defining a width
for a text field.
I realize that in the ideal world we would separate these concerns out. But
having tried it the HTML::StickyWidgets way and the application widget way,
I know that I like the application widget way better. I think there is
room for your idea though but I haven't honestly thought about it.
Re: Real Widgets and Template Languages
Posted by Cees Hek <ce...@sitesuite.net>.
On Tue, 22 May 2001, Gunther Birznieks wrote:
> What I am really looking for is a library that abstracts and allows widgets
> to be developed that are tied to an application not to a set of HTML
> necessarily. I guess I will start by providing an example of what I want
> based on what we currently do in our Java framework when he use Templating
> there. I'd like it if someone has developed the same thing in Perl that we
> could reuse, otherwise, we may need to write this.
This sounds very useful and powerful. I've been looking for a project to
help out with, and this one sounds interesting to me. Let me know if you
want some help developing it, or someone to bounce ideas off...
> <TR>
> <TH>First Name:</TH><TD><widget id="fname"/></TD>
> <TH>Last Name:</TH><TD><widget id="lname"/></TD>
> <TH>Comments</TH><TD><widget id="comments"/></TD>
> </TR>
One thing that I think is very important is to let designers have control
over the look and feel of the interface. Your widget library should have
some mechanism to allow a template designer to specify attributes for a
widget (like width, height, colour, etc...).
<widget id="comments" width="100" height="5" color="red">
- or -
<widget id="comments" attr="width=100; height=5; color=red">
You can still allow programmers to have control over how the data is
verified, and other attributed like maxlength for text fields and
such.
Of course these attributes will not be useful in every type of widget.
ie if the programmer decided that this widget is going to be a text field
instead of a textarea, then the above height attribute would be useless,
and ignored.
Cees
RE: Real Widgets and Template Languages [resend]
Posted by David Harris <dh...@drh.net>.
[[ This is a resend.. did some cutting and pasting of code into telnet
windows that messed it up through shell expansion. My bad. ]]
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ <table border=0> ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__card_type->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my ($require, $values, $labels) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate($values->[0]) );
return undef;
},
}], }],
[qq[ <tr><td><font size="-1">Expiration</font></td><td> ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_month->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ $CUST::DbAccess::Lookup::ccard__exp_year->{$_}, $_ ] }
@$CUST::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ </td></tr> ]],
[q[
<tr><td colspan=2><font size="-1">
<img src="/resources/clear.gif" height=10 width=1><br>
If the name on the card is different than your billing
address you can enter it below.
<br><img src="/resources/clear.gif" height=10 width=1><br>
</font></td></tr>
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ </table> ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la <widget name=card_name> that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.<p>
]],
[qq[ <b>Billing information</b><p> ]],
[{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
"Billing"),
undef,
[qq[ <b>Credit card information</b><p> ]],
[{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
CUST::InterfaceUtil::credit_card_fields(),
undef,
]
It's great for reuse.
The default_by_name does something interesting: it imports all the defaults
for the fields (_looks_like and _required and _size) information from the
database table. If I change the size of a text field in a table all the
forms which use that text field are automatically updated. (However, I
should change the default_by_name system so that it doesn't need to be
specified when I'm including default confirmation. Like I said, this system
is straining under the evolution.)
I can contribute this library if it would help. I'll warn you that there's
not too much documentation. I can also contribute some examples of my code
that use the library.
David Harris
President, DRH Internet Inc.
dharris@drh.net
http://www.drh.net/
Re: Real Widgets and Template Languages
Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 22 May 2001, Gunther Birznieks wrote:
> Does anyone have a widget framework like this? I think the closest I found
> to widget abstraction is SmartWorker, but it is not abstract in quite the
> way that I want above.
We're planning to do something like this as a taglib in XSP for AxKit.
It's quite a big task though, as we want widgets to also be intelligent in
the way they are mapped to forms processing code.
> Has someone done this already?
Struts. But you knew that already :-)
--
<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 **
\\//
//\\
// \\
RE: Real Widgets and Template Languages
Posted by David Harris <dh...@drh.net>.
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a form I specify in one list all of the
elements along with the type of data and any validation routines. Some
information about how the form should look is also included. My code then
automatically generates the form (it looks like a dialogue box) from this
information. The same informational hash is used to parse the form and
validate the data. If the data is not validated correctly, the form is shown
again with the validation errors and the data remaining sticky. If the data
is validated then it is returned in a hash.
Here is a simplified example of the widget definitions for a form that
allows a customer to charge money on their credit card into their balance:
[
amount => { width => "20", same_line => 1,
label => "Amount to charge (in dollars)", _label => "Amount to
charge",
_looks_like => "number", _required => 1, },
[{ addl_require => [{
type => "sub",
fields => [qw(amount)],
sub => sub {
my ($require, $values, $labels) = @_;
return "You may not initiate a charge for less than \$5.00."
if ( $values->[0] < 5 );
return "You may not initiate a charge for more than \$900.00. If
you really do want to
charge this much, then you need to call us and we can do it
for you."
if ( $values->[0] > 900 );
return undef;
},
}], }],
]
Note the elements "label", "_label", and "same_line" for the "amount" widget
specify display attributes. (My actual definition of the form contains more
than the widgets themselves but rather the whole look and feel form.) The
element "_required" specifies that this widget may not be left blank by the
user. The element "_looks_like" with value "number" specifies that the value
in this text box must be a number. I can also specify dates, free text, or
whatever I needed as types for the widget.
The "addl_require" stuff you see is a way of in lining an additional
requirement: this requires that the value for the amount field must be
between 5.00 and 900.00. The additional requirement is tied specifically to
the fields that it is dependent on. For example, if the field "amount" was
left blank thus not satisfying the "_required" specification, then this
addl_require you see would not be checked, as its dependants has not been
verified.
Here is another example. This is the definition for the form elements to
collect credit card information:
[
[qq[ <table border=0> ]],
card_type => { c_table => 1, et => "select", label => "Card type",
options => [
map { [ ::DbAccess::Lookup::ccard__card_type->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__card_type__keys
],
},
card_num => { c_table => 1, width => 30, label => "Card number" },
[{ addl_require => [{
type => "sub",
fields => [qw(card_num)],
sub => sub {
my (, , ) = @_;
return "The credit card number you entered is not valid."
if ( not Business::CreditCard::validate(->[0]) );
return undef;
},
}], }],
[qq[ <tr><td><font size="-1">Expiration</font></td><td> ]],
exp_month => { c_blank => 1, et => "select", label => "Exp month",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_month->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_month__keys
],
},
[qq[ / ]],
exp_year => { c_blank => 1, et => "select", label => "Exp year",
options => [
map { [ ::DbAccess::Lookup::ccard__exp_year->{euclid.drh.net},
euclid.drh.net ] }
@::DbAccess::Lookup::ccard__exp_year__keys
],
},
[qq[ </td></tr> ]],
[q[
<tr><td colspan=2><font size="-1">
<img src="/resources/clear.gif" height=10 width=1><br>
If the name on the card is different than your billing
address you can enter it below.
<br><img src="/resources/clear.gif" height=10 width=1><br>
</font></td></tr>
]],
card_name => { width => 30, c_table => 1, label => "Name on card" },
[qq[ </table> ]],
]
This above code is showing the strains of evolution of my system. :-) Notice
all the [qq[ ... ]] constructs which allow HTML text to be inlined.
Originally there wasn't much inlined HTML, as each widget knew how to
display itself and its label. However I was stuck to one specific display
look constrained me. So I told the widgets how to print their labels with
"c_blank" and "c_table" parameters and inlined HTML code.
This really calls for the widgets to be embedded directly in the HTML
template which contains the formatting a la <widget name=card_name> that
Gunther proposed.
This above code actually sits in a subroutine that returns a list of the
definitional information. This list is then simply included other places so
I can write stuff like this:
[
[qq[
Enter your billing information and credit card.<p>
]],
[qq[ <b>Billing information</b><p> ]],
[{ default_by_name => CUST::DbAccess::Cust::default_by_name("custs") }],
CUST::InterfaceUtil::opensrs_contact_fields($country_select_box, "bill",
"Billing"),
undef,
[qq[ <b>Credit card information</b><p> ]],
[{ default_by_name => CUST::DbAccess::Ccard::default_by_name("ccards") }],
CUST::InterfaceUtil::credit_card_fields(),
undef,
]
It's great for reuse.
The default_by_name does something interesting: it imports all the defaults
for the fields (_looks_like and _required and _size) information from the
database table. If I change the size of a text field in a table all the
forms which use that text field are automatically updated. (However, I
should change the default_by_name system so that it doesn't need to be
specified when I'm including default confirmation. Like I said, this system
is straining under the evolution.)
I can contribute this library if it would help. I'll warn you that there's
not too much documentation. I can also contribute some examples of my code
that use the library.
David Harris
President, DRH Internet Inc.
dharris@drh.net
http://www.drh.net/