Re: Time/Date Selector

[Sean Legassick <se...@informage.net>]

In message <B7...@apache.org>, Jason van Zyl 
<jv...@apache.org> writes
>Hi,
>
>I was trying to get rid of the last of the ECS code in Turbine this
>morning and came across some tid bits I'd like to share :-)

Hi Jason,

Firstly as I haven't been contributing much in recent months, but have 
been vaguely keeping track in stolen moments of the refactoring you've 
been doing, a big +1 for the work you're doing. Turbine's architecture 
was definitely starting to get messy and out of control, and 3 looks 
like it's going to be really clean. Nice!

>I removed ECS from HtmlMail simply by using the string equivalents
>for the tags. I didn't really want to convert the Selector classes
>so I added some logic to the build to exclude them for now if the
>ecs jar isn't present (I'm going to remove it from cvs).

However I'm a bit perplexed by the extent of your antipathy towards ECS. 
I've got no axe to grind here, but ECS seems to be like a great way to 
handle programmatic generation of HTML tags. I remember the point at 
which the mail classes were converted ot use ECS rather than hard-coded 
strings and I thought this was a great step forward. What you've done 
strikes me as retrograde.

Sure I can see the argument for removing ECS from the core page 
generation logic when templates are being used, and I'm fully behind the 
refactoring you've done there.

However what's the problem with having some utility classes that 
generate HTML using ECS? If a user doesn't want to use them they won't 
need the ECS jar around - it's only needed for building.

>Than I discovered that TimeSelector and DataSelector are referenced
>in BaseValueParser??? Why are html widgets being referenced in
>in a generic parser. I would like to get rid of these references.

This was me, and Jeff's explanation is on the money. Perhaps the string 
constants in TimeSelector and DateSelector should live elsewhere - like 
TurbineConstants?

When I wrote the convenience code in BaseValueParser that pieces the 
*Selector form parameters together into a Date object (should be 
Calendar now actually) I wanted to ensure that the classes were using 
the same string constants for the form parameter name suffixes.

-- 
Sean Legassick
sean@informage.net
         Als Mensch kann mir nichts menschliches Fremd sein

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Time/Date Selector

[Sean Legassick <se...@informage.net>]

In message <B7...@apache.org>, Jason van Zyl 
<jv...@apache.org> writes
>I personally don't see any point in using ECS to generate a couple of HTML
>tags. In the email classes it probably doesn't really matter but this could
>still be considered a view of sorts and I think that it should be fully
>customizable using templates. If someone wanted to change the html than they
>are reliant on a developer again.

Sure, it's not a big deal - personally I still prefer ECS for 
programmatic HTML generation, and I'll note that hard-coded Strings are 
no more customizable by the designer.

>Because the designer has zero control of the generation of html. Say you
>originally used a Selector box for a widget, now this is placed in the
>context for the designer. But what if the designer wants to use a set of
>checkboxes or change the way the information is presented? Take a list and
>generate the widget. I think that ECS is too limiting.

Okay, these date and time selection widgets could probably be 
implemented as macros in VTL. Right now we have the ECS versions though 
and they're useful.

>>> Than I discovered that TimeSelector and DataSelector are referenced
>>> in BaseValueParser??? Why are html widgets being referenced in
>>> in a generic parser. I would like to get rid of these references.
>>
>> This was me, and Jeff's explanation is on the money. Perhaps the string
>> constants in TimeSelector and DateSelector should live elsewhere - like
>> TurbineConstants?
>
>I don't think any widgets should be referenced in the controller, to me that
>doesn't make sense. Anything used for the view should be completely
>separately. ECS or not, widgets should not be reference in controller code,
>I think that just creates problems.

Sure, but equally the controller (as in the application logic rather 
than the framework code) should ideally not need to know exactly what 
input widget was used when interpreting form input. The point of the 
BaseValueParser logic was to make the choice of input widget invisible 
to the application controller code - it can just call getDate and let 
the parser worry about whether the date was supplied as a single string 
or separately as day, month and year.

Note that dividing the date input into day, month and year is not 
particularly dependent on the DateSelector widget - any widget which 
uses separate inputs for the three values could make use of that 
functionality in BaseValueParser.

It does make sense then to make the actual string suffixes for the 
parameters generally available, ideally in such a way that they can be 
easily retrieved from a VTL template for use in a VTL widget rather than 
the ECS one. Is there any mechanism for general framework string 
constants being available through the context?

Note also that this kind of functionality in parameter parsing is 
extensible - an application can specify that it wishes to use a custom 
subclass of DefaultParameterParser in TR.properties.

>I think the core of Turbine should be devoid of all tools and utilties: in
>the repository and in the logic. When the refactoring the core turbine
>classes will number somewhere on the order of 40-50 classes. There is no
>reason that we can't also make a tools repository or have a set of utilities
>but I think these types of classes should vary indendently of the core.
>
>If tools and utilties are in the same repository as the core than inevitibly
>someone will couple them to the core because it seems convenient but it's a
>hindrance to any future refactoring and improvement of the core because the
>core is coupled to code that really has nothing to do with the core.

+1 on this - tools should not be coupled to the core.

-- 
Sean Legassick
sean@informage.net
         Ek is 'n man: niks menslik is vreemd vir my nie

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Time/Date Selector

[Jason van Zyl <jv...@apache.org>]

On 8/6/01 6:03 PM, "Sean Legassick" <se...@informage.net> wrote:

 
>> I removed ECS from HtmlMail simply by using the string equivalents
>> for the tags. I didn't really want to convert the Selector classes
>> so I added some logic to the build to exclude them for now if the
>> ecs jar isn't present (I'm going to remove it from cvs).
> 
> However I'm a bit perplexed by the extent of your antipathy towards ECS.
> I've got no axe to grind here, but ECS seems to be like a great way to
> handle programmatic generation of HTML tags. I remember the point at
> which the mail classes were converted ot use ECS rather than hard-coded
> strings and I thought this was a great step forward. What you've done
> strikes me as retrograde.

I personally don't see any point in using ECS to generate a couple of HTML
tags. In the email classes it probably doesn't really matter but this could
still be considered a view of sorts and I think that it should be fully
customizable using templates. If someone wanted to change the html than they
are reliant on a developer again.
 
> Sure I can see the argument for removing ECS from the core page
> generation logic when templates are being used, and I'm fully behind the
> refactoring you've done there.
> 
> However what's the problem with having some utility classes that
> generate HTML using ECS? If a user doesn't want to use them they won't
> need the ECS jar around - it's only needed for building.

Because the designer has zero control of the generation of html. Say you
originally used a Selector box for a widget, now this is placed in the
context for the designer. But what if the designer wants to use a set of
checkboxes or change the way the information is presented? Take a list and
generate the widget. I think that ECS is too limiting.
 
>> Than I discovered that TimeSelector and DataSelector are referenced
>> in BaseValueParser??? Why are html widgets being referenced in
>> in a generic parser. I would like to get rid of these references.
> 
> This was me, and Jeff's explanation is on the money. Perhaps the string
> constants in TimeSelector and DateSelector should live elsewhere - like
> TurbineConstants?

I don't think any widgets should be referenced in the controller, to me that
doesn't make sense. Anything used for the view should be completely
separately. ECS or not, widgets should not be reference in controller code,
I think that just creates problems.
 
> When I wrote the convenience code in BaseValueParser that pieces the
> *Selector form parameters together into a Date object (should be
> Calendar now actually) I wanted to ensure that the classes were using
> the same string constants for the form parameter name suffixes.

I think this is outside the scope of the BaseValueParser and we should find
some other way to do this.

I think the core of Turbine should be devoid of all tools and utilties: in
the repository and in the logic. When the refactoring the core turbine
classes will number somewhere on the order of 40-50 classes. There is no
reason that we can't also make a tools repository or have a set of utilities
but I think these types of classes should vary indendently of the core.

If tools and utilties are in the same repository as the core than inevitibly
someone will couple them to the core because it seems convenient but it's a
hindrance to any future refactoring and improvement of the core because the
core is coupled to code that really has nothing to do with the core.

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org