At 08:50 PM 5/23/01 -0400, Adi Fairbank wrote:
>Stephen,
>
>I read your proposal and I like it a lot.  I will help filling out the
>HTML::Widget::HTML* space (in your package structure suggestion).
>
>However, I like Gunther's suggestion for a namespace of Widget:: better than
>HTML::Widget::, because it will not be exclusively HTML, but WML, JS10,
>etc.  But either one is fine with me.

What is JS10? JavaScript version 1.0? Should we call it JavaScript or 
EcmaScript? :)

I actually think that Perl objects to generate JS validation routines is 
worthy of its own abstraction. There are several reasons for this. One is 
that you need to be able to decouple the javascript tags. So if you 
validate, say, a text field to contain only numbers, the routine to do it 
should be in the header of the HTML but the widget that gets drawn needs to 
reference the right routine. So such a library that can generate this stuff 
needs to be a little more wise and the new JS tags have to be intelligent 
to know about each other so that a tag at the top of the page that 
generates the routines can know ahead of time what routines to generate 
based on the widgets that appear later in the page.

It seems solvable but also a bit hard and scary.

While it is possible to make JS-specific components (as a first cut)... I 
wouldn't want to lose site of the fact that the JS could be an add-on and 
maybe it is possible that it should be it's own abstract that the widget 
set needs to be able to hook into but isn't built into separate widgets.

The red flag comes in seeing examples like

Widget::HTML::DateDropDown
Widget::HTML::UserAgentDate
Widget::HTML::JSDate

if it is like this, then you may have many date widgets flying aroudn that 
are all HTML widgets but share features with a lot of copy and paste 
between them which isn't very clean OO. As I write this I am quite sleepy 
and so please forgive my lack of constructive critique.

I just want to point it out and maybe we can revisit this. We don't have to 
code the JS abstraction but if it is clearly outlined where stuff like JS 
should interact with the widget library and where it should not, then it 
will make the job of developing the widget library easier.

>Sounds fun!

I agree!


Reply via email to