Re: [Perl-widget-developer] thoughts on design

[Issac G. <ne...@wr...>]

Stephen:

  Maybe put a bit of general info either on the list or somewhere on
sourceforge explaining what you're expecting your base classes to grow
towards... It would help me, at least, get a better understanding of what
you've done, and hopefully get us all, as a team, focused on a single vision
of the what's and how's of implementing this in a consistant form...  I
personally am still unsure of what some things in the base classes are meant
to do...

  Issac

----- Original Message -----
From: "Stephen Adkins" <ste...@of...>
To: <JG...@TA...>; <per...@li...>
Cc: <JG...@TA...>
Sent: Friday, June 01, 2001 16:50
Subject: Re: [Perl-widget-developer] thoughts on design


> James,
>
> Sounds like your thing is Themes.
> We want the Themes concept to work its way into the PWL.
> Please take a look at the software, Widget-0.01 found at
>
>    http://www.officevision.com/pub/Widget/
>
> Begin to understand the classes and the existing framework.
> Then start proposing on this list
>
>   1. a class or set of classes to implement Themes
>   2. XML configuration format to configure Themes
>
> When you understand how the PWL works and we all concur on
> how Themes fits in, you can go berzerk.
>
> Stephen
>
> At 10:53 PM 5/31/2001 -0500, James G Smith wrote:
> >Here are some thoughts and ideas I've had and played with in
> >various forms over the last few months regarding themeing and
> >html rendering.  Some things might be useful, some not.
> >
> >Background:  I am currently working on some PHP code to provide
> >an environment in which scripts can be independent from most
> >content which, in turn, can be independent of the look of the
> >page.  The theme object is called to render anything from form
> >input tags to tables.
> >
> >For a live example, browse https://neo.tamu.edu/xyzzy/ .  This is
> >a non-public alpha installation being used for current
> >development.  The Directory feature uses the theme object to
> >render the list of found records in LDAP as well as the actual
> >record itself.  You could think of the list as a list widget that
> >the theme object provides for the script.
> >
> >I am currently developing a table rendered in PHP that will
> >render using <pre>..</pre> text instead of tables.  This will
> >allow for a theme that uses no tables for those browsers that
> >have a hard time rendering tables.
> >
> >In addition to providing some components/widgets for the scripts,
> >the theme object also handles the page layout.  At the moment, I
> >have enumerated 47 (16 with all edge content intact + 31 with
> >some edge component missing) different ways to layout a page with
> >central and edge content.  For example, the default look of the
> >above development site is as follows:
> >
> >+---------+
> >|   Top   |
> >+---------+
> >|         |
> >| Content |
> >|         |
> >+---------+
> >|  Bottom |
> >+---------+
> >
> >I don't have the proper data structure initialized for this
> >particular layout, but if I did, the user would have the choice
> >of having this rendered using frames or tables.  Currently, it
> >will only use tables.  This is done without the script or theme's
> >knowledge.
> >
> >http://hex.tamu.edu/test.php has three themes available for
> >demostration.  It also shows what the ldap directory object
> >returns from a successful lookup (me).
> >
> >Back to the Present:  I would like to bring as much of this logic
> >as possible over into the Perl world.  I think a widget system
> >would be a good way to do it.  A theme could possibly be a widget
> >factory -- I ask it for a widget that can draw a table, and it
> >gives me one.  I don't have to know what the package is or the
> >specifics of configuring it, as long as I can give it a set of
> >headers and the table contents and it can draw a table for me.
> >
> >I could give the theme object back a set of widgets and it could
> >render the page, allowing for the user to choose frames or no
> >frames (for example) without causing drastic problems in the code
> >composing the page.  Perhaps this could be done with the template
> >idea....
> >
> >Widgets could still be used outside of the widget factory, but
> >the code would need to know which widget it was using.  The
> >factory would need to be aware of all the types of widgets being
> >used in the site.  It could also handle the burden of doing the
> >general configuration of widgets, allowing the scripts to focus
> >on the items that make the widget unique/useful in their context.
> >
> >This could also be done (I think) parallel with other efforts
> >such as the Widget::HTML::Template idea (milestone 5).  The two
> >might even complement each other.
> >--
> >James Smith <JG...@TA...>, 979-862-3725
> >Texas A&M CIS Operating Systems Group, Unix
> >
> >_______________________________________________
> >Perl-widget-developer mailing list
> >Per...@li...
> >http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
> >
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>