You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Vjeran Marcinko <vj...@tis.hr> on 2004/04/30 14:41:19 UTC
Simplicity not functionality
I totaly agree with you Peter. Although I am working quite shortly with
Tapestry (less than 2 months), I am huge fan, and my opinion is that
Tapestry doesn't have to go much higher in functionality (my only wishful
additions would be to allow storing pages in dir hierarchy, and enabling all
form field components to be plugged into validation framework, not just
ValidField, and I know these issues are on TO-DO list for future versions),
but simplifying and redesigning some existing functionality should be of
higher importance.
I think also that need to understand page/component lifecycle, tied together
with complex usage of properties and parameters is major obstacle for
newbies. In last 3 months I worked with both Struts and Turbine/Velocity, so
both of them are quite fresh in my memory, and I know very well their
disadvantages, and lack of power comparing to Tapestry, and I would *never*
go back to them, but I can surely tell you one thing - they *are* simplier
(especially Turbine/Velocity), mostly because of Tapestry's complexity in
things mentioned above.
-Vjeran
----- Original Message -----
From: "Petter Måhlén" <pe...@elevance.se>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Friday, April 30, 2004 12:03 AM
Subject: RE: Page/component initialization complicated?
> I've always initialized my stuff in prepareForRender(). It
> is only called
> once and you don't need the isRewinding() logic.
>
> I've yet to hear from someone that initializing here is a bad
> approach.
> It's been working fine for me.
In fact, I agree with Vjeran that the initialisation flow of pages and
components is complicated - to me, it's a part of the major weakness in
Tapestry (which includes the whole parameter/property design). I love the
rest of the framework, and I am thorougly impressed with the framework
design and code, so I am sure that this part will reach the same level soon.
:)
/ Petter
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Michael Hamilton <mi...@actrix.gen.nz>.
I'm converting an application I wrote in Zope/Zope-Page-Templates
to Tapestry/Jboss/Hibernate. Tapestries templating, expressions,
and language integration seem cleaner and more straight forward
than Zope's ZPT - which greatly eases the learning curve.
Speaking as a newbie, I can echo Vjeran Marcinko's statement that:
> I think also that need to understand page/component lifecycle, tied
> together with complex usage of properties and parameters is major
> obstacle for newbies.
I haven't really got a good handle on all of this yet, but
I would like to comment a little about property declaration.
Property declaration includes non-persistent and persistent
options - this is incomplete - data can also be browser-page
persistent via hidden fields. This is such an important form
of persistence I would suggest elevating it to a first-class
property option. Something like:
<property-specification
name="timeRecordId"
type="int"
persistenceType="BrowserHidden"/>
If the the run-time generation of the associated html could be
made the responsibility of the Form component or some
single Form sub-component, then declaring hidden data would be
greatly simplified.
On Sat, 01 May 2004 00:41, Vjeran Marcinko wrote:
> I totaly agree with you Peter. Although I am working quite shortly with
> Tapestry (less than 2 months), I am huge fan, and my opinion is that
> Tapestry doesn't have to go much higher in functionality (my only
> wishful additions would be to allow storing pages in dir hierarchy, and
> enabling all form field components to be plugged into validation
> framework, not just ValidField, and I know these issues are on TO-DO
> list for future versions), but simplifying and redesigning some existing
> functionality should be of higher importance.
> I think also that need to understand page/component lifecycle, tied
> together with complex usage of properties and parameters is major
> obstacle for newbies. In last 3 months I worked with both Struts and
> Turbine/Velocity, so both of them are quite fresh in my memory, and I
> know very well their disadvantages, and lack of power comparing to
> Tapestry, and I would *never* go back to them, but I can surely tell you
> one thing - they *are* simplier (especially Turbine/Velocity), mostly
> because of Tapestry's complexity in things mentioned above.
>
> -Vjeran
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Simplicity not functionality
Posted by "Filip S. Adamsen" <fi...@stubkjaer-adamsen.dk>.
+1.
> On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>
> >> But maybe other people hate the idea of more attributes and would
> >> prefer a single string
> >> that lists all the pertinent info.
> >
> > I too prefer the attribute approach over a combined string...
> >
> > Richard
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Geoff Longman <gl...@intelligentworks.com>.
+1 for me too.
Geoff
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Saturday, May 01, 2004 11:37 AM
Subject: Re: Simplicity not functionality
> +1 on attributes over free form strings also.
>
>
> On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>
> >> But maybe other people hate the idea of more attributes and would
> >> prefer a single string
> >> that lists all the pertinent info.
> >
> > I too prefer the attribute approach over a combined string...
> >
> > Richard
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Richard Lewis-Shell <rl...@mac.com>.
Why not just use bindings? Perhaps the ValidField can 'consume' some of its
informal bindings to be used to configure the Validator. I say 'consumed'
so they don't get rendered as-is. Though we could just create 1st class
custom 'sub-components' for each typical Validator - ala
contrib:Number/Date/StringField. I really don't think its much work, and
with 3 or 4 components we can probably cover 90+% uses of ValidField. Then
the bindings wouldn't be informal...
R
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@comcast.net>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Sunday, May 02, 2004 10:17 PM
Subject: RE: Simplicity not functionality
> There's a third option!
>
> How about:
>
> <component id="inputName" type="ValidField">
> <proeprty name="validationType" value="string"/>
> <property name="required" value="true"/>
> <property name="minimumLength" value="5"/>
> <binding name="value" expression="address.name"/>
> <static=binding name="displayName" value="Name"/>
> </component>
>
> The <property> element exists to support meta-data ... we should start
using it. In the above
> example, we've
> made ValidField's validator parameter optional (perhaps by providing a
default value), and the
> configuration for the validator is drawn from the meta-data for the field.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > Sent: Saturday, May 01, 2004 11:37 AM
> > To: Tapestry users
> > Subject: Re: Simplicity not functionality
> >
> >
> > +1 on attributes over free form strings also.
> >
> >
> > On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
> >
> > >> But maybe other people hate the idea of more attributes and would
> > >> prefer a single string
> > >> that lists all the pertinent info.
> > >
> > > I too prefer the attribute approach over a combined string...
> > >
> > > Richard
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Jamie Orchard-Hays <ja...@dang.com>.
+1 on that
On May 2, 2004, at 8:17 AM, Howard M. Lewis Ship wrote:
> There's a third option!
>
> How about:
>
> <component id="inputName" type="ValidField">
> <proeprty name="validationType" value="string"/>
> <property name="required" value="true"/>
> <property name="minimumLength" value="5"/>
> <binding name="value" expression="address.name"/>
> <static=binding name="displayName" value="Name"/>
> </component>
>
> The <property> element exists to support meta-data ... we should start
> using it. In the above
> example, we've
> made ValidField's validator parameter optional (perhaps by providing a
> default value), and the
> configuration for the validator is drawn from the meta-data for the
> field.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
>> -----Original Message-----
>> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> Sent: Saturday, May 01, 2004 11:37 AM
>> To: Tapestry users
>> Subject: Re: Simplicity not functionality
>>
>>
>> +1 on attributes over free form strings also.
>>
>>
>> On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>>
>>>> But maybe other people hate the idea of more attributes and would
>>>> prefer a single string
>>>> that lists all the pertinent info.
>>>
>>> I too prefer the attribute approach over a combined string...
>>>
>>> Richard
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Todd O'Bryan <to...@mac.com>.
Personal opinion of course, but I *HATE* the whole property
construction with names and values. I hate looking at the.html file to
find inputName and then having to flip to the .page file to figure out
what the heck it is, and then back to the .html file, and so on.
Having Tapestry-specific attributes is one of the beautiful
simplicities of the framework, and Geoff's ability to check them in
Spindle makes it easy to see if something's wrong with your HTML.
I think it's good to have the option of the <property> element
construction, but it should definitely exist as a last resort, not a
first one.
Todd
On May 2, 2004, at 8:17 AM, Howard M. Lewis Ship wrote:
> There's a third option!
>
> How about:
>
> <component id="inputName" type="ValidField">
> <proeprty name="validationType" value="string"/>
> <property name="required" value="true"/>
> <property name="minimumLength" value="5"/>
> <binding name="value" expression="address.name"/>
> <static=binding name="displayName" value="Name"/>
> </component>
>
> The <property> element exists to support meta-data ... we should start
> using it. In the above
> example, we've
> made ValidField's validator parameter optional (perhaps by providing a
> default value), and the
> configuration for the validator is drawn from the meta-data for the
> field.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
>> -----Original Message-----
>> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> Sent: Saturday, May 01, 2004 11:37 AM
>> To: Tapestry users
>> Subject: Re: Simplicity not functionality
>>
>>
>> +1 on attributes over free form strings also.
>>
>>
>> On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>>
>>>> But maybe other people hate the idea of more attributes and would
>>>> prefer a single string
>>>> that lists all the pertinent info.
>>>
>>> I too prefer the attribute approach over a combined string...
>>>
>>> Richard
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Geoff Longman <gl...@intelligentworks.com>.
But what about expressions? i.e. having the minimumLength value come from a
page property.
Geoff
----- Original Message -----
From: "Petter Måhlén" <pe...@elevance.se>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Sunday, May 02, 2004 3:21 PM
Subject: RE: Simplicity not functionality
> This looks really good to me!
>
> > -----Original Message-----
> > From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> > Sent: den 2 maj 2004 14:18
> > To: 'Tapestry users'
> > Subject: RE: Simplicity not functionality
> >
> >
> > There's a third option!
> >
> > How about:
> >
> > <component id="inputName" type="ValidField">
> > <proeprty name="validationType" value="string"/>
> > <property name="required" value="true"/>
> > <property name="minimumLength" value="5"/>
> > <binding name="value" expression="address.name"/>
> > <static=binding name="displayName" value="Name"/>
> > </component>
> >
> > The <property> element exists to support meta-data ... we
> > should start using it. In the above
> > example, we've
> > made ValidField's validator parameter optional (perhaps by
> > providing a default value), and the
> > configuration for the validator is drawn from the meta-data
> > for the field.
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Tapestry: Java Web Components
> > Creator, HiveMind
> > http://howardlewisship.com
> >
> >
> > > -----Original Message-----
> > > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > > Sent: Saturday, May 01, 2004 11:37 AM
> > > To: Tapestry users
> > > Subject: Re: Simplicity not functionality
> > >
> > >
> > > +1 on attributes over free form strings also.
> > >
> > >
> > > On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
> > >
> > > >> But maybe other people hate the idea of more attributes and would
> > > >> prefer a single string
> > > >> that lists all the pertinent info.
> > > >
> > > > I too prefer the attribute approach over a combined string...
> > > >
> > > > Richard
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > tapestry-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > tapestry-user-help@jakarta.apache.org
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Simplicity not functionality
Posted by Petter Måhlén <pe...@elevance.se>.
This looks really good to me!
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: den 2 maj 2004 14:18
> To: 'Tapestry users'
> Subject: RE: Simplicity not functionality
>
>
> There's a third option!
>
> How about:
>
> <component id="inputName" type="ValidField">
> <proeprty name="validationType" value="string"/>
> <property name="required" value="true"/>
> <property name="minimumLength" value="5"/>
> <binding name="value" expression="address.name"/>
> <static=binding name="displayName" value="Name"/>
> </component>
>
> The <property> element exists to support meta-data ... we
> should start using it. In the above
> example, we've
> made ValidField's validator parameter optional (perhaps by
> providing a default value), and the
> configuration for the validator is drawn from the meta-data
> for the field.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
>
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > Sent: Saturday, May 01, 2004 11:37 AM
> > To: Tapestry users
> > Subject: Re: Simplicity not functionality
> >
> >
> > +1 on attributes over free form strings also.
> >
> >
> > On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
> >
> > >> But maybe other people hate the idea of more attributes and would
> > >> prefer a single string
> > >> that lists all the pertinent info.
> > >
> > > I too prefer the attribute approach over a combined string...
> > >
> > > Richard
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > tapestry-user-help@jakarta.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Simplicity not functionality
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
There's a third option!
How about:
<component id="inputName" type="ValidField">
<proeprty name="validationType" value="string"/>
<property name="required" value="true"/>
<property name="minimumLength" value="5"/>
<binding name="value" expression="address.name"/>
<static=binding name="displayName" value="Name"/>
</component>
The <property> element exists to support meta-data ... we should start using it. In the above
example, we've
made ValidField's validator parameter optional (perhaps by providing a default value), and the
configuration for the validator is drawn from the meta-data for the field.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Saturday, May 01, 2004 11:37 AM
> To: Tapestry users
> Subject: Re: Simplicity not functionality
>
>
> +1 on attributes over free form strings also.
>
>
> On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>
> >> But maybe other people hate the idea of more attributes and would
> >> prefer a single string
> >> that lists all the pertinent info.
> >
> > I too prefer the attribute approach over a combined string...
> >
> > Richard
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
+1 on attributes over free form strings also.
On May 1, 2004, at 6:04 AM, Richard Lewis-Shell wrote:
>> But maybe other people hate the idea of more attributes and would
>> prefer a single string
>> that lists all the pertinent info.
>
> I too prefer the attribute approach over a combined string...
>
> Richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Richard Lewis-Shell <rl...@mac.com>.
> But maybe other people hate the idea of more attributes and would
> prefer a single string
> that lists all the pertinent info.
I too prefer the attribute approach over a combined string...
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Simplicity not functionality
Posted by Todd O'Bryan <to...@mac.com>.
On Apr 30, 2004, at 9:20 AM, Howard M. Lewis Ship wrote:
> I think we'll have a streamlined way to identify the
> validations for a particular field, for instance, say
> "string,required,minlength=5" instead of
> having to create a <bean> with the same information.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> Creator, HiveMind
> http://howardlewisship.com
>
How about <input type="text" validator="String" required="true"
minLength="5">
if only so that you don't have to remember the order of the string for
validation and to more
closely mirror the way things are done with other components.
You could imagine <input type="text" validator="Integer" min="10"
max="99"> and
other similar things. You might even want to create Phone, Zip, etc.
validators with
JavaScript to reformat input to make it conform to some standard
format. For instance,
I hate it when forms make me input phone numbers as three separate
fields, or instruct
me to leave out dashes, etc., when it's so easy to read in anything and
reformat it to
(###) ###-#### as soon as the user tabs out of the field.
But maybe other people hate the idea of more attributes and would
prefer a single string
that lists all the pertinent info.
Todd
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Simplicity not functionality
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
The cycle has generally been: Add a feature in release N, improve and simplify it in release N+1.
Tapestry is very much alive and constantly improving.
My approach has always been to start very, very strict and gradually ease up. So, in Tapestry 2.3,
you had to explicitly list every page and every component in your application in your application
specification. In Tapestry 3.0 (2.3 + 1 = 3.0 :-) ), you could omit those page and component lists,
and even the app spec itself. This works very well ... the opposite approach (seen in many other
frameworks) is to introduce a quick-and-dirty, under-realized idea (Java code inside JSPs, for
example) and fixing that involves bringing order out of chaos, which is virtually impossible.
In 3.1, I can see lots of areas where we can further simplify; I think *everyone* wants all form
fields to work with the validation delegate. I think Form will have a delegate by default that you
can override with an application-specific delegate. I think all the form control components will now
integrate with the validation delegate. I think we'll have a streamlined way to identify the
validations for a particular field, for instance, say "string,required,minlength=5" instead of
having to create a <bean> with the same information.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Vjeran Marcinko [mailto:vjeran@tis.hr]
> Sent: Friday, April 30, 2004 8:41 AM
> To: Tapestry users
> Subject: Simplicity not functionality
>
>
> I totaly agree with you Peter. Although I am working quite
> shortly with
> Tapestry (less than 2 months), I am huge fan, and my opinion is that
> Tapestry doesn't have to go much higher in functionality (my
> only wishful
> additions would be to allow storing pages in dir hierarchy,
> and enabling all
> form field components to be plugged into validation
> framework, not just
> ValidField, and I know these issues are on TO-DO list for
> future versions),
> but simplifying and redesigning some existing functionality
> should be of
> higher importance.
> I think also that need to understand page/component
> lifecycle, tied together
> with complex usage of properties and parameters is major obstacle for
> newbies. In last 3 months I worked with both Struts and
> Turbine/Velocity, so
> both of them are quite fresh in my memory, and I know very well their
> disadvantages, and lack of power comparing to Tapestry, and I
> would *never*
> go back to them, but I can surely tell you one thing - they
> *are* simplier
> (especially Turbine/Velocity), mostly because of Tapestry's
> complexity in
> things mentioned above.
>
> -Vjeran
>
> ----- Original Message -----
> From: "Petter Måhlén" <pe...@elevance.se>
> To: "'Tapestry users'" <ta...@jakarta.apache.org>
> Sent: Friday, April 30, 2004 12:03 AM
> Subject: RE: Page/component initialization complicated?
>
>
> > I've always initialized my stuff in prepareForRender(). It
> > is only called
> > once and you don't need the isRewinding() logic.
> >
> > I've yet to hear from someone that initializing here is a bad
> > approach.
> > It's been working fine for me.
>
> In fact, I agree with Vjeran that the initialisation flow of pages and
> components is complicated - to me, it's a part of the major
> weakness in
> Tapestry (which includes the whole parameter/property
> design). I love the
> rest of the framework, and I am thorougly impressed with the framework
> design and code, so I am sure that this part will reach the
> same level soon.
> :)
>
> / Petter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org