perl-widget-developer Mailing List for Perl Widget Library (Page 5)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

93177

interpret configuration

Up On the News - GSNH closes Up Friday, After-Market News Release - Get GSNH Quote Here. sophism.
http://moneycentral.msn.com/detail/stock_quote?Symbol=gsnh

After weeks of speculation it's finally here, and the news is even bigger than we thought. relict.

We first knew something was up with GSNH when news came out Thursday regarding Drill LOMT #1. But GSNH really popped up on our radar with Friday's After-Market news. GSNH has announced its partners for the LOMT #1 sidetrack well and you are not going to believe who they are. hum.

GSNH Names Partners for LOMT #1 Sidetrack Well murderous.
Friday October 27, 4:05 pm ET obsidian.
HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: seashore
* Patterson-UTI (Nasdaq: PTEN), Revenue: 2.23 billion, UP 63.30% clash
* Schlumberger (NYSE: SLB), Revenue: 17.90 billion, UP 34.00% synonym
* Halliburton (NYSE: HAL), Revenue: 22.90 billion, UP 13.40% cardiology

Oct. 27, 2006 (BUSINESS WIRE) - GSNH Names Partners for Sidetrack Well... contemplate
http://biz.yahoo.com/bw/061027/20061027005324.html?.v=1

GSNH has been releasing steady news worldwide, from Yahoo Finance, AOL, & MSN Money to Marketwatch & Bloomberg---even the NYSE & the NASDAQ have gotten in on the action. Exposure for GSNH is expansive. The increased frequency of news led us to believe that something big was coming for GSNH, and as usual, we were dead-on right. calvin

Oct. 26, 2006 (BUSINESS WIRE)  GSNH to Drill LOMT #1... stein.
http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029

Oct. 12, 2006 (BUSINESS WIRE)  GSNH Reports Drilling Success... aggressor.
http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb=

Oct. 11, 2006 (BUSINESS WIRE)  GSNH Announces the Anthony 33... systemwide.
http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH

Oct. 4, 2006 (BUSINESS WIRE)  GSNH...285 million in Probable Reserves... dung.
http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU

Friday's After-Market news on GSNH and its newfound partnership with these major corporations (over 43 billion in revenue combined) is just the beginning. We believe that there is even bigger news coming, and as always, we are bringing you the news ahead of time, ahead of everyone else, and ahead of a major spike in GSNH stock price.

chromic battle bill

errant torrent
Up On the News - GITH Up (+12.50% with 8X Average Volume) already on Friday's closing-market News Release. broadside.

Get GITH Quote Here. raffle.
http://money.cnn.com/quote/quote.html?symb=GITH

Friday's Closing-Market News On GITH pintail.
Oracle, SQL Server and Sybase Can't All Be Wrong.  Staffing companies are the #1 employer in the USA today, and IT staffing with GITH is leading the revolution. morris.

NEW YORK, Oct. 20, 2006 (PRIMEZONE) -- GITH -- A recent report based on a survey of fourteen hundred Chief Information Officers predicts steady growth in Q4 for technology IT hiring. Thirty-four percent of CIOs surveyed plan to add IT staff and none anticipated cutbacks in personnel. cautionary.

GITH sources personnel for companies and offers custom software solutions related to Oracle, SQL Server and Sybase and software such as SAP, JD Edwards, and PeopleSoft. The report done on behalf of Robert Half Technology specifically mentions that 71% of CIOs anticipated needing personnel having skill sets related to Oracle, SQL Server, and DB2. embrittle.

Read the entire news release from Friday Closing-Market debar.
http://biz.yahoo.com/pz/061020/107201.html

GITH has been releasing steady news worldwide, from Yahoo Finance & Bloomberg to MSN & CNN Money, even the NASDAQ. Exposure for GITH is expansive.  The increased frequency of news leads us to believe that something big is coming for GITH. glutamine.

Oct. 17, 2006 (PRIMEZONE) -- Executive Job Market Report Forecasting 'War For Talent' Bolsters Comments by GITH President coolheaded.
http://news.moneycentral.msn.com/ticker/article.asp?Symbol=US:GITH&Feed=PZ&Date=20061017&ID=6111313

Oct. 14, 2006 (PRIMEZONE) -- GITH  Foresees Growth in Fourth Quarter... posts increase in sales revenue... aplomb.
http://www.bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GITH:US&sid=aMMgvBh5UWMA

Sept. 25, 2006 (PRIMEZONE) -- Market forces combining over the next few years to drive up demand for a decreasing supply of specialized IT personnel.  GITH is leading the 21st Century revolution... fountain.
http://www.nasdaq.com/aspxcontent/NewsStory.aspx?cpath=20060925\ACQPMZ200609251523PRIMZONEFULLFEED105738.htm&symbol=gith&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&symbol=&selected=GITH&selecteddisplaysymbol=GITH&coname=GLOBAL%20IT&lo

burette dew cinnabar

Hi,

I saw your brochure at 

   http://www.daybreakdirect.com/marcom/MarcomMaster_22.pdf

Presumably that is the set of widgets you are looking for.

The perl-widget project at SourceForge is defunct.
However, I continue the work for Perl widgets under the
auspices of the P5EE project (which would also be defunct
except that I keep working on it).

   http://www.officevision.com/pub/p5ee

In other words, there is no real community built up
around these tools.  However, I use them in production
and am actively developing them.  I release them as
free software on CPAN, so there is no limit to people
using them.

   http://search.cpan.org/~spadkins/App-Options/
   http://search.cpan.org/~spadkins/App-Context/
   http://search.cpan.org/~spadkins/App-Repository/
   http://search.cpan.org/~spadkins/App-Widget/

I have every intention of continuing to work on
them and improve them.

I also organize Atlanta.pm, the Atlanta perl users' group,
so there may be some pool of development talent available
to join with me in working on such a project.

If that hasn't scared you away yet, I am interested in
knowing more about your project requirements and any proposed
arrangement that you might foresee.
Please send me what you have so I might evaluate it further.

 * What developers do you already have?
 * What pieces have they already developed?
 * What technologies are they using?
   (Perl? CGI? mod_perl? Linux? Windows?)
 * What sorts of timeframes are you looking at?
 * What are your key milestones/releases?
 * What do you propose for payment terms?
   (fixed price? per unit of work? hourly? what rates?)
 * What limitations (if any) would you put on including
   the output of our work into the Free Software
   distributions (i.e. App-Widget) that we release on
   CPAN? (i.e. general widget code OK, domain-specific 
   code not OK, general images OK, domain-specific images
   not OK)

Thanks. I look forward to hearing from you.

Stephen Adkins

On Thu, 2005-02-10 at 19:19, DOUG wrote:
> Hello:

> I am looking for a number of widgets to be developed. I also am
> looking for designers, that can take the initial protype designs that
> we have found, and create our own. The tools that I need widgets for
> can be found on a pdf and some flash presentations that are at
> www.daybreakdirect.com/marcom. If you know of anybody who can assist
> us it would be greatly appreciated. We are a pre-start up company, but
> we do have several thousand dollars set aside to fund this
> development. Doug
> 
> 512-342-8220 icq 236-880-147
-- 
Stephen Adkins <ste...@of...>
OfficeVision.com

Hello:

I am looking for a number of widgets to be developed. I also am looking for
designers, that can take the initial protype designs that we have found, and
create our own. The tools that I need widgets for can be found on a pdf and
some flash presentations that are at www.daybreakdirect.com/marcom. If you
know of anybody who can assist us it would be greatly appreciated. We are a
pre-start up company, but we do have several thousand dollars set aside to
fund this development. Doug

512-342-8220 icq 236-880-147

Hi,

There's been no traffic on this list for a while.
This email is to update you on what has been going on.

I am using the PWL in production at one of my customers.
This causes me to periodically update the CVS repository with
the latest code.

However, my attention has switched to the P5EE (Perl 5 Enterprise
Environment) project at

   http://www.officevision.com/pub/p5ee/

Everything in the Perl Widget Library that was good has found
its way into P5EE, so the PWL has no independent future.
Anyone of you subscribed to this list who still are interested
in Perl widgets as they were being developed here should subscribe
to the P5EE mailing list and follow unfolding developments there.

Here is a brief history of how this came to be.

 * I have long sought a way to create complex HTML UI's out of
   reusable components (widgets)
 * Discussion began on the mod_perl list concerning a widget
   library, to which I responded by starting this Sourceforge
   project.
 * I think what was envisioned by most participants was a very 
   lightweight library.
 * I, however, envisioned tight integration with Controller
   and Repository (persistence) components to facilitate
   active controls (with encapsulated event handling and bubbling
   to container widgets) and data-aware controls.
 * As I developed the concept, I realized that the Controller
   component really deserved to be central to a more far-reaching
   framework than just a widget library.  Furthermore, many other
   facilities (Config, debugging, etc.) were being duplicated
   between my separately developed Perl Widget Library and
   Perl Data Repository distributions.
 * Discussion began on the mod_perl list concerning a
   "J2EE for Perl" framework (later dubbed "P5EE").  I recognized
   this as a project that I wanted to be involved with, and I 
   responded by beginning work on the definition of P5EE.
      http://www.officevision.com/pub/p5ee/
 * It became apparent over time that many of the services I was
   working on for the Perl Widget Library were really appropriate
   for the P5EE, and the Widget library itself was but a small
   piece of the P5EE.  So I migrated all of the PWL code over
   to the P5EE project, and further development continues there.

So the Perl Widget Library is a dead end project, but all of the
promise that it held is alive and well in the P5EE project.
Feel free to unsubscribe from this mailing list.
From now on, all of the Perl Widget activity will be in the 
P5EE project.

Stephen

Hi,

At 10:45 PM 10/10/2001 +0200, Issac Goldstand wrote:
>On the one had, I think it looks incredible.  I really love it.
>On the second hand, it looks incredibly heavy, and looks like most of the
>work is server side, requiring a full refresh from the server every time you
>click on a widget - that could get long and tiring really fast, don't you
>think?
>
>Just my $0.02...  Keep up the great work.
>
>  Issac

You provide a good opportunity for some more comments...

 1. In general, web application user interfaces stink compared to their
    client-server (or stand-alone) counterparts.  This is due to (1) a 
    lack of graphical richness, and (2) the delay incurred by a round 
    trip to the server.  The strength of web applications is that they
    are universally accessible (any browser, anywhere).  The Perl Widget
    Library is designed to (eventually) address both of these weaknesses
    while not sacrificing the strength of universal access.
 2. The demo (AppFrame.pm) is an attempt to see how close I can make the
    look and feel of a web application come to a familiar desktop
    application (i.e. Outlook). 
 3. How heavy is it? One demo page I checked was about 32K. (All of the
    images get cached, so they don't get downloaded every request.)
    This compares to 16K for a typical Yahoo! page. Not too heavy.
    In fact, if it *looks* heavy but it is not, this would be good.
    I have a 56K modem, and the app is currently a CGI program.  It
    returns to me in about 3 seconds after each click.  After it gets
    a mod_perl Controller, it should perform even better.
    Also, the dressing all around the main application "window" is the
    result of AppFrame.pm.  An application is a collection of screens,
    dressed up with an application frame to provide navigation, toolbars,
    etc.  If one desired a "lighter" look, one could write a different
    application frame widget.
 4. Server-side processing? All web programming uses server side
    processing.  Universal access requires that the application run without
    recourse to JavaScript, Java, or other client-side execution engine.
    However, once I get the "round-trip to the server on every click"
    method working, I can begin to optimize using JavaScript if available
    on the user's browser.  Good candidates for these optimizations are
    the TreeView, the SelectorView (outlook bar), and type validation on 
    data entry widgets.
 5. The current demo has the AppFrame implemented as a table instead of
    frames.  Frames are coming, but I wanted to demonstrate how far we
    could get without frames.  The application will look more polished
    when the AppFrame can use frames, and not everything gets refreshed
    every click.  Furthermore, when we use JavaScript, we can begin to 
    exploit some browser-specific features of IE4 
    (window.offscreenBuffering).  This will make the the page refreshes
    much less "tiring" to look at.
 6. The trick in all of this is to create a simple design so that all of
    the complexities of how to implement widgets are hidden within each
    widget's code. (frames or no frames? javascript or no javascript?
    offscreenBuffering or not? style sheets or not? etc.)  
    That's why I keep reworking the core plumbing.  My vision is that 
    developers can really assemble a web application from parts (each 
    potentially very complex) without having to know what goes on inside
    each part.  Furthermore, developers with skills in JavaScript or
    Java can create widgets which are easy to plug in without the (perl)
    developer having to know anything about those client-side technologies.

If I claimed that all of these things were possible, not many people would
believe me.  (I sometimes wonder myself.) ;-)  That's why I keep posting
demo URL's to show what I have been able to make work.

I'll keep you all posted.

Stephen

On the one had, I think it looks incredible.  I really love it.
On the second hand, it looks incredibly heavy, and looks like most of the
work is server side, requiring a full refresh from the server every time you
click on a widget - that could get long and tiring really fast, don't you
think?

Just my $0.02...  Keep up the great work.

  Issac

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

----- Original Message -----
From: "Stephen Adkins" <ste...@of...>
To: <per...@li...>
Sent: Wednesday, October 10, 2001 22:54
Subject: [PW-dev] latest demonstration of widgets

> Hi,
>
> FYI.
>
> Here is another demonstration of widgets in action.
> It demonstrates that although some people may decide to use
> widgets within other tools (i.e. Template Toolkit, Embperl, etc.)
> (which is definitely a supported use!), I envision being able
> to build up entire applications as compound widgets.
>
> See the demonstration of a Widget::HTML::AppFrame here.
>
>    http://www.officevision.com/cgi-bin/pub/Widget/wcgi/app
>
> (Please note: this application does not *do* anything, so
> don't ask.)
>
> Stephen
>
> P.S. This is still alpha quality and not checked into CVS yet.
>
>
>
> _______________________________________________
> Perl-widget-developer mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>

Hi,

FYI.

Here is another demonstration of widgets in action.
It demonstrates that although some people may decide to use
widgets within other tools (i.e. Template Toolkit, Embperl, etc.)
(which is definitely a supported use!), I envision being able
to build up entire applications as compound widgets.

See the demonstration of a Widget::HTML::AppFrame here.

   http://www.officevision.com/cgi-bin/pub/Widget/wcgi/app

(Please note: this application does not *do* anything, so
don't ask.)

Stephen

P.S. This is still alpha quality and not checked into CVS yet.

Hi,

At 11:08 PM 10/3/2001 +0800, Gunther Birznieks wrote:
>That's really cool! I'd love to hear what you felt the weaknesses and 
>strengths were.
>

Gunther asked, so here are some comments.

They probably won't mean anything to anyone because my head is buried
in the internals. And I'm not really in a state to take a lot of
community feedback yet. I'm just trying to keep you abreast of what
is going on.

Strengths
 * true visual component model
   Widgets can be written not knowing how they will be used and then
   assembled via coded containers and config file. Complex widgets
   can be created from simpler widgets.  The complexity of the
   implementation is completely hidden.
 * UI state maintenance
   State is maintained cleanly across HTTP requests, but each widget
   has a reference to its own state without knowing about the other
   widgets' states.  State maintenance is done without server storage,
   cookies, or URL rewriting. (i.e. <input type=hidden>)
 * Container-element relationships
   Both the parent-child inheritance and container-element containment
   relationships are implemented
 * Event bubbling
   Events can be processed by the widget or bubbled up to its
   container for processing (i.e. a TreeView widget wants to
   process open() and close() events on its folder nodes without
   bothering its container.  A select() event on one of its leaf
   nodes needs to be bubbled to the container widget for processing.)
 * Attribute configuration
   A tremendous amount of information is determined at runtime via
   configuration data.  The only things that have to be know to a 
   developer about a widget are its name and a set of methods it is
   assumed to support.  Any number of implementations of this interface
   may be configured to go at runtime.
 * Attribute absorption
   Attributes can be absorbed from the container widget, enabling the
   promise of themes (styles) and internationalization.

Weaknesses
 * my desire to do state maintenance strictly by <input type=hidden>
   variables with no server-side storage is showing limitations
   (particularly for complex, frame-aware widgets).
 * I need to refine how I separate and combine the configuration
   data with the runtime user data.  I don't want to copy all of the
   configuration data (which could include large multi-language
   dictionaries) into each session, but I need to merge what was
   configured with what has been overridden.
 * I require too much overhead in my simplest widgets. A simple
   non-active, single-valued entry widget (i.e. <input type=text>)
   should be incredibly simple and fast with virtually no memory
   footprint.  I have ideas for making simple widgets simpler
   while continuing to provide power to 
 * Simple inter-widget state setting could be made much more
   efficient (I think). I have to instantiate a widget to set its
   state currently, whereas it might be much more efficient to 
   tell the controller to do it.  The controller can use its
   knowledge of the internal state of widgets so that the widget
   doesn't even need to be instantiated.
 * I currently required widgets to handle the x() and y() events
   associated with image buttons (<input type=image>) instead of
   doing it for them in the controller.
 * I don't currently have a Message Authentication Code (MAC) on
   the Storable/MIME state which I embed in each returned page.

Stephen

That's really cool! I'd love to hear what you felt the weaknesses and 
strengths were.

At 03:24 PM 10/2/2001 -0400, Stephen Adkins wrote:
>Hi,
>
>This is my annual ;-) message to let you all know that the
>Perl Widget Library is still alive.
>
>An example of a real, active widget is the TreeView
>widget.  See it in action here.
>
>    http://www.officevision.com/cgi-bin/pub/Widget/wcgi/tree
>
>I have not made any releases recently because I have actually been
>using it in a production project.  This is both good and bad.
>
>  1. it has proven the concepts decisively
>  2. it has revealed weaknesses that will make be rewrite
>     some of the infrastructure, requiring modifications to all
>     widget code.
>
>In other words, the Perl Widget Library has an increasingly
>promising future but is still currently in flux.
>I have recently committed the latest to CVS in case anyone
>is interested in looking at it.
>However, I consider it still in middle-alpha state.
>
>Stephen
>
>
>
>_______________________________________________
>Perl-widget-developer mailing list
>Per...@li...
>https://lists.sourceforge.net/lists/listinfo/perl-widget-developer

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/

Hi,

This is my annual ;-) message to let you all know that the
Perl Widget Library is still alive.

An example of a real, active widget is the TreeView
widget.  See it in action here.

   http://www.officevision.com/cgi-bin/pub/Widget/wcgi/tree

I have not made any releases recently because I have actually been
using it in a production project.  This is both good and bad.

 1. it has proven the concepts decisively
 2. it has revealed weaknesses that will make be rewrite
    some of the infrastructure, requiring modifications to all
    widget code.

In other words, the Perl Widget Library has an increasingly
promising future but is still currently in flux.
I have recently committed the latest to CVS in case anyone
is interested in looking at it.
However, I consider it still in middle-alpha state.

Stephen

On Sun, 5 Aug 2001, Gunther Birznieks wrote:

> If it's not more than a few hundred lines of code in one .pm and if it's 
> compatible with Stephan's stuff then I wouldn't mind it being posted to the 
> list.

Since Stephen has just come out with 0.04, I'll see if everything still
conforms.  Then I'll post it to the list.

Cees

If it's not more than a few hundred lines of code in one .pm and if it's 
compatible with Stephan's stuff then I wouldn't mind it being posted to the 
list.

At 09:25 PM 8/2/2001 +1000, Cees Hek wrote:

>I guess we've all got some good excuses :)
>
>Work has been really busy lately, and since I code perl all day, i didn't
>feel like coding perl at night as well...
>
>I have however thrown together a 'complex' widget.  It's another date
>widget, but this one uses a layer with a calendar that allows you to
>browse through the months and click on a date.  Essentially it's your
>regular date picker done in a layer.
>
>The reason I did this one is so that we have something to work on to
>integrate Language support, javascript handling, and browser detection.
>
>Let me know what you guys want me to do with it (commit in cvs or post to
>the list).  It's completely in it's own .pm so it shouldn't affect any
>other code.
>
>Later
>
>Cees
>
>
>On Thu, 2 Aug 2001, Gunther Birznieks wrote:
>
> > Likewise, I am hoping that in a few weeks, I can officially stop Java
> > coding and actually deal with Perl code again.  I have been slammed on
> > projects before and now recovering from OReillyCon.
> >
> > Sorry I haven't been more constructive than simply saying words rather 
> than
> > backing up with code like others (eg you and I think James Smith).
> >
> > At 03:24 PM 8/1/2001 -0400, Stephen Adkins wrote:
> > >Hi,
> > >
> > >Not much activity on this list in the last month...
> > >
> > >I just wanted to give everyone a heads-up that after 2 wks vacation,
> > >2 wks scrambling to catch up on the contract which pays my bills,
> > >I'm now working on a contract for the next two weeks which will
> > >be using the Perl Widget Library and the Template Toolkit heavily.
> > >
> > >So expect more news on this list soon.
> > >
> > >I have worked on simplifying the configuration data structure and
> > >making it a native Perl config (rather than XML).
> > >
> > >It should be ready for prime time soon.
> > >
> > >More later,
> > >
> > >Stephen
> > >
> > >
> > >
> > >_______________________________________________
> > >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
> >
>
>--
>Cees Hek
>SiteSuite Corporation
>ce...@si...
>
>
>_______________________________________________
>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/

Hi,

I fixed the issues which were holding up the completion of
using a straightforward Perl config file.
I have made a release today of Widget-0.04.tar.gz.
See

   http://www.officevision.com/cgi-bin/acoc/dev/Widget/ptp/index.html

for live demonstrations.
See

   http://www.officevision.com/pub/Widget/

for the familiar home page with links to the tar.gz file.
An example of internationalization is at

   https://www.officevision.com/cgi-bin/acoc/dev/Widget/ptp/Select.html

(Pardon the poor internationalization example. I have no idea if Canadian
French differs from French French in the illustrated way.)

Now to torture test it by using it in a real application...
More soon.

Stephen

I guess we've all got some good excuses :)

Work has been really busy lately, and since I code perl all day, i didn't
feel like coding perl at night as well...

I have however thrown together a 'complex' widget.  It's another date
widget, but this one uses a layer with a calendar that allows you to
browse through the months and click on a date.  Essentially it's your
regular date picker done in a layer.

The reason I did this one is so that we have something to work on to
integrate Language support, javascript handling, and browser detection.

Let me know what you guys want me to do with it (commit in cvs or post to
the list).  It's completely in it's own .pm so it shouldn't affect any
other code.

Later

Cees

On Thu, 2 Aug 2001, Gunther Birznieks wrote:

> Likewise, I am hoping that in a few weeks, I can officially stop Java 
> coding and actually deal with Perl code again.  I have been slammed on 
> projects before and now recovering from OReillyCon.
> 
> Sorry I haven't been more constructive than simply saying words rather than 
> backing up with code like others (eg you and I think James Smith).
> 
> At 03:24 PM 8/1/2001 -0400, Stephen Adkins wrote:
> >Hi,
> >
> >Not much activity on this list in the last month...
> >
> >I just wanted to give everyone a heads-up that after 2 wks vacation,
> >2 wks scrambling to catch up on the contract which pays my bills,
> >I'm now working on a contract for the next two weeks which will
> >be using the Perl Widget Library and the Template Toolkit heavily.
> >
> >So expect more news on this list soon.
> >
> >I have worked on simplifying the configuration data structure and
> >making it a native Perl config (rather than XML).
> >
> >It should be ready for prime time soon.
> >
> >More later,
> >
> >Stephen
> >
> >
> >
> >_______________________________________________
> >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
> 

-- 
Cees Hek
SiteSuite Corporation
ce...@si...

Likewise, I am hoping that in a few weeks, I can officially stop Java 
coding and actually deal with Perl code again.  I have been slammed on 
projects before and now recovering from OReillyCon.

Sorry I haven't been more constructive than simply saying words rather than 
backing up with code like others (eg you and I think James Smith).

At 03:24 PM 8/1/2001 -0400, Stephen Adkins wrote:
>Hi,
>
>Not much activity on this list in the last month...
>
>I just wanted to give everyone a heads-up that after 2 wks vacation,
>2 wks scrambling to catch up on the contract which pays my bills,
>I'm now working on a contract for the next two weeks which will
>be using the Perl Widget Library and the Template Toolkit heavily.
>
>So expect more news on this list soon.
>
>I have worked on simplifying the configuration data structure and
>making it a native Perl config (rather than XML).
>
>It should be ready for prime time soon.
>
>More later,
>
>Stephen
>
>
>
>_______________________________________________
>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/

Hi,

Not much activity on this list in the last month...

I just wanted to give everyone a heads-up that after 2 wks vacation,
2 wks scrambling to catch up on the contract which pays my bills,
I'm now working on a contract for the next two weeks which will
be using the Perl Widget Library and the Template Toolkit heavily.

So expect more news on this list soon.

I have worked on simplifying the configuration data structure and
making it a native Perl config (rather than XML).

It should be ready for prime time soon.

More later,

Stephen

At 11:19 PM 7/8/2001 +0800, Gunther Birznieks wrote:
>I pretty much like all of this.
>
>But I don't quite understand where background-color is turned into 
>backgroundColor and why. Is the widget code then taking this internal 
>capital case and turning it back into background-color when it actually 
>generates the HTML?
>
...

Hi,

Short answer is...

  where: It is transformed in Widget::HTML::Stylizable
         See the translation table in %style_attrib.
         (It is not convention magic which changes internal caps to
         dashes.) (Please note that the next version, 0.04, will
         probably change the way I implement styles.)

  why:   I needed to choose some convention for multi-word attributes,
         and the internal-caps style (backgroundColor) works with
         named parameter conventions (-backgroundColor => '#ffffff')
         (with no quotes) whereas internal dashes do not 
         (-background-color => '#ffffff') (which fails because "dash"
         is the "minus" operator).

The longer answer includes the following discussion:

  What should the attribute be called in the Perl API (the Perl
     Widget Library) if it maps directly to an attribute of an underlying
     physical rendering technology?

Example:

The background color of something might be translated into

   * bgcolor (HTML of <body>, <td>)
   * background-color (CSS style sheets and HTML STYLE='background-color:
#ffffff')
   * backgroundColor (Javascript method of setting the attribute)

There are any number of rendering technologies which may be used by a given
widget.  However, we should not need to know the particulars about it.
Therefore, we should scan the potention rendering technologies (for naming
precedents so that we don't add yet another naming precedent for no reason).
Then we should *adopt* that convention as the *native* convention for the
attributes of widgets in the PWL.

Therefore, I chose the Javascript-style internal-caps convention for all
PWL attributes because:

 a. it mirrors a commonly used internal rendering technology (Javascript)
 b. it works with Perl for named parameter syntax

Stephen

I pretty much like all of this.

But I don't quite understand where background-color is turned into 
backgroundColor and why. Is the widget code then taking this internal 
capital case and turning it back into background-color when it actually 
generates the HTML?

At 02:22 PM 6/23/2001 -0400, Stephen Adkins wrote:
>Hi,
>
>There is a new snapshot of the Perl Widget Library (all available in CVS):
>Widget-0.03.  You can download it from
>
>    http://www.officevision.com/pub/Widget/
>
>This achieves a couple major milestones.  As per the Changes file, this
>release includes:
>
>    1. demonstrate that the Perl Widget Library works with the Template 
> Toolkit
>    2. add overriding of <widgetType> attributes at the <widget> level
>    3. incorporate a "container" concept into widgets, and event bubbling
>    4. incorporate concepts of attribute absorption (inheritance, in a
>container sense)
>    5. implied containers using dots (.) in name (i.e. "birth_dt" is implied
>container for "birth_dt.day")
>    6. change all attributes from "dash" to "internal capital"
>("background-color" to "backgroundColor")
>    7. rework the DateDropDowns widget to use dynamic (not pre-configured)
>sub-widgets
>
>This release is what I would call the first genuinely usable release.
>I am beginning to use it in my projects.
>Notably lacking are the yet-to-be-added features of
>
>    A. default configuration file is Perl
>    B. multi-lingual widgets (it's coming soon)
>
>Again, the documentation is way out of date, but I have a liberal dose of
>examples
>in the distribution, so using the Widgets should be easier from both CGI
>programs
>and Template Toolkit templates.  Mod_perl support is not complete, but it
>might
>work fine with Apache::Registry.
>
>I am going out of town for two weeks until July 10, so there will be *very*
>little activity from me on this project until then.  Expect a Widget-0.10
>near the end of July.  At that time, I will be ready to announce the
>availability
>of the Perl Widget Library to the modperl list and the Template Toolkit list.
>
>1. PWL AND TEMPLATE TOOLKIT
>
>I have created a script in the cgi-bin directory called "ptp", for
>"Perl Template Pages" (as opposed to JSP for "Java Server Pages").
>It is a general purpose CGI template driver through which I demonstrate
>the templates I've written.
>
>I have created sample templates in the "templates" directory.
>You can see them in operation here.
>
>    http://www.officevision.com/cgi-bin/pub/Widget/ptp/
>
>If you use the LOAD_PERL option in your template processor, you can use the
>following syntax in your templates.
>
>    <html>
>    <head><title>Widget Demo</title></head>
>    <body>
>    <form method='POST'>
>    [% USE wc = Widget %]
>
>    [% CALL wc.state.value("w001","Hello") %]
>
>    [%
>       wc.widget(
>          name = "w001",
>          widgetClass = "Widget::HTML::TextField",
>          backgroundColor = "#ffa0a0",
>          size = 24,
>       ).display
>    %]
>
>    </form>
>    </body>
>    </html>
>
>This usage does not require a config file at all.
>(The limitations to this usage become apparent for more complex,
>active widgets, and they are overcome by using the config file.)
>Take a look at the examples for more information.
>
>I probably will write a proper plugin for the Template Toolkit
>sometime, but this gets us by for now.
>
>Note that if the configuration file is used and there are no
>overrides in the template, the syntax for displaying a widget
>reduces to:
>
>    [% wc.widget("w001").display %]
>
>This is not as simple as we would like it, but it's not too bad
>
>2. CONFIG PRECEDENCE
>
>The configuration of each widget is now assembled by the controller
>and cached for each widget.
>
>The widget config is a simple hash which is the result of several
>complementary sources:
>
>    1. config of the widget (in Config) (which override widgetType)
>    2. optional config of the widget's widgetType (in Config)
>    3. config of container widget
>    4. args to the widget_config() call, usually coming from the widget
>       constructor. some of these are defaults, other are overrides.
>
>This more sophisticated configuration management paves the way for
>themes and internationalization, because widgets absorb attributes
>from their container.
>
>See Widget::Controller->widget_config() for more details.
>
>3. STYLES
>
>CSS style sheet attributes are now being supported (such as backgroundColor
>of TextField (<input type=text>) widgets.  However, you can expect
>significant rework here.  I am not content with the overhead it imposes
>on widgets that don't have style sheet attributes.
>
>One of my major design principles is:
>
>    As we make widgets feature-rich, we must not put an undue processing
>    burden on users who choose to use only a small number of the features.
>    The additional burden should be a simple check to see if a feature
>    needs to be invoked based on a single configuraton attribute.
>
>Much more to come on styles...
>
>4. ATTRIBUTE ABSORPTION
>
>This is a major new feature.  Absorption is how element widgets gain the
>attribute values of their container widgets.  It is to be distinguished
>from attribute *inheritance*, where a child widget inherits data and
>behavior (in an OO sense) from its parent widget class.
>
>5. CONTAINERS AND IMPLIED CONTAINERS
>A widget can be made an element of a containing widget by specifying the
>"container" argument.  Alternatively, if a widget name has a "." in it
>and no other container has been supplied, it is assumed to be contained
>by the implied widget.
>(i.e. "birth_dt" is implied container for "birth_dt.day")
>
>6. ATTRIBUTES USE INTERNAL CAPITALS LIKE JAVASCRIPT
>
>Per Cees Hek's good suggestion, I use the Javascript convention for
>referring to multi-word attributes, including CSS attributes which have
>a dash separating the words. (i.e. "background-color" is "backgroundColor")
>
>7. COMPOUND WIDGETS CAN USE DYNAMIC SUB-WIDGETS
>
>It's taken me this long to catch up to Cees Hek's good observation that
>subwidgets created from compound widgets (such as Widget::HTML::DateDropDowns)
>should not need to be configured in the config file.
>
>8. EXISTING WIDGETS NOT YET VERY EXCITING
>
>Please note that in accordance with my promise at the outside, the widgets
>available for use are actually very limited.  I am getting the plumbing
>right before plunging into really interesting widgets.  I have done a little
>prototyping with a TreeView widget.  See the non-active, visual prototype at
>
>    http://www.officevision.com/pub/Widget/treedemo.html
>
>It's when we get widgets like this that I believe the promise of the
>Perl Widget Library really begins to become reality.
>
>See the TODO list for other things that are on my mind for releases
>yet to come.
>
>Feedback is welcome and appreciated, but please don't expect much
>response for 2-1/2 weeks.
>
>Thanks,
>
>Stephen

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/

Some of you I think mentioned being at the YAPC-Montreal. Just wondering 
how that went. Did any of you get to meet up?

I am still planning on being at O'Reilly Con in another couple of weeks for 
anyone going there.

Later,
    Gunther

Thinking about themes and widgets, I'm working on a Page widget 
based on some PHP code I have.

The basic interface:

 $page = $wc -> widget("Page", (class => "Front"));

 # for default layout
 # +---+---------+---+
 # |   |    T    |   |
 # | L +---------+ R |
 # | T |         | T |
 # | L |         | R |
 # | L |         | R |
 # | B +---------+ B |
 # |   |    B    |   |
 # +---+---------+---+

 # if configuration file can define widgets, the following four 
 # lines could be in the config file.
 $page -> T("Stuff at the top of the page");
 $page -> B("Stuff at the bottom of the page");
 $page -> LTLLB("Stuff along the left top, left, and left bottom");
 $page -> RTRRB("Stuff along the right top, right, and right bottom");

 $body = $page -> ARRAY;

 @{$body} = (
    # array of widgets and strings
 );

 print $page;

 __END__

The Page object could be configured to use any of a variaty of 
layouts, some dependent on the configuration class.

This kind of widget might benefit from allowing widgets to be 
created based on the configuration file instead of explicit calls 
in Perl.

I think my present configuration code allows for reading multiple 
configuration files.  This allows for global configurations with 
local configuration files representing content, for example.  
This gets us dangerously close to AxKit without the stylesheets :)
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

I finally got XML::Parser to not dump core on me, so now I can 
continue testing/developing in a mod_perl env. (solution: make 
Apache use the system expat lib instead of its own).

Basically, I've gotten the XML configuration to the point where 
the following is possible:

<configuration>
  <classes>
    <map>
      <citys>
        <hash>
          <a>Albuquerque</a>
          <b>Belen</b>
          <c>Chama</c>
          <e>Elephant Butte</e>
          <f>Farmington</f>
        </hash>
      </citys>
      <city>Albuquerque</city>
      <interstate>
        10
        <values>
          <hash>
            <10>Interstate 10</10>
            <25>Interstate 25</25>
            <40>Interstate 40</40>
          </hash>
        </values>
      </interstate>
    </map>
  </classes>
  <widgets>
    <title>Page title</title>
  </widgets>
</configuration>

Defines a class called 'map' which defines the values for two 
widgets named 'city' and 'interstate'.  One widget with the name 
'title' is configured with a value of 'Page title'.

I'm still trying to think about how to do plurals from singular 
forms (value -> values).  This means that the 'city' tag 
designates the default value for the widget of that name while 
'citys' or 'cities' (hopefully) will designate the set of valid 
values.  'value' and 'values' are still valid tags.

Anyone want anything in an XML configuration that isn't here?  
Possibilities include code to validate widget values:

<configuration>
  <classes>
    <date>
      <class id="month">
        <validate>
          <[CODE
if($value > 0 && $value < 13) { return $value; }
return 0;
          ]>
        </validate>
      <class>
    </date>
  </classes>
</configuration>

I haven't even thought about how to work that into the code yet.
--
James Smith <JG...@TA...>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

Probably would be OK. We already have a library of widgets in Java. If you 
want, I can tar up our code and send them out. They aren't perfect though 
and have grown over the last year of writing web apps with them in JSPs.

The widget taglib is distinctly separate from the widget classes themselves 
so the widget code should be theoretically reusable.

At 11:10 PM 6/23/01 -0400, Stephen Adkins wrote:
>Hi,
>
>This is just a heads up as to where I would like the Perl Widget Library
>to go.  90% of the work will be in building the right abstractions
>and then building the library of widgets: icons, HTML, CSS, Javascript,
>etc.
>
>When the Perl Widget Library is off and flying, I envision beginning
>another SourceForge project called "java-widget", or
>the Java Widget Library.  There would be so much that the two projects
>would share.
>
>Just food for thought.
>
>Stephen
>
>
>
>_______________________________________________
>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/

Hi,

This is just a heads up as to where I would like the Perl Widget Library
to go.  90% of the work will be in building the right abstractions
and then building the library of widgets: icons, HTML, CSS, Javascript,
etc.

When the Perl Widget Library is off and flying, I envision beginning
another SourceForge project called "java-widget", or 
the Java Widget Library.  There would be so much that the two projects
would share.

Just food for thought.

Stephen

2001	Jan	Feb	Mar	Apr	May (8)	Jun (132)	Jul (3)	Aug (6)	Sep	Oct (6)	Nov	Dec
2002	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2005	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec (9)
2007	Jan (2)	Feb (2)	Mar (1)	Apr (1)	May	Jun	Jul	Aug (19)	Sep (6)	Oct (5)	Nov (5)	Dec (3)
2008	Jan	Feb (7)	Mar (34)	Apr (13)	May (15)	Jun (5)	Jul (14)	Aug (6)	Sep (6)	Oct (3)	Nov (1)	Dec

perl-widget-developer Mailing List for Perl Widget Library (Page 5)

perl-widget-developer — Discussion about bugs and further development of Perl Widgets