tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Lewis-Shell" <rlewissh...@mac.com>
Subject Re: Upgrading to 3.0 (cvs HEAD) from 2.2
Date Tue, 03 Jun 2003 20:17:36 GMT
Neil - this sounds reasonable.  I think you should just commit away.  As I
understand it those components are broken, so you are not going to make them
worse, and there is an imminent release planned so you could get the fixes
into that release rather than waiting for beta-2...

R

----- Original Message -----
From: "Neil Clayton" <neil@cloudnine.net.nz>
To: "Tapestry users" <tapestry-user@jakarta.apache.org>; <hlship@attbi.com>
Sent: Wednesday, June 04, 2003 6:15 AM
Subject: Re: Upgrading to 3.0 (cvs HEAD) from 2.2


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK.

finally, after actually fixing the issue, I *think* I see what's going on.
I think that ValidatingTextField requires the following patch, to make the
"text" parameter use the "value" parameter and correctly share the code from
the superclass.

I've posted this here, since I want to confirm with those who know more
about
this than I before I commit. I'll also raise the necessary bug for it, if I
can get someone to confirm I'm right. It could be that I'm mad, using it
wrong, am mad ... or ....

I figure the same change will probably need to be made to NumericField and
DateField.


On Monday 02 Jun 2003 8:09 pm, hlship@attbi.com wrote:
> It's simpler than you think.  <reserved-parameter> has nothing to do with
> it, that's simply related to filtering any informal parameters.
>
> For each formal parameter, enhancer creates a binding property
(fooBinding)
> and a parameter property (foo).  If either property already exists, it is
> used. Otherwise, it creates the attribute and the pair of accessor
methods.
>
> If parameter direction is "custom", the default, then the parameter
> property is not created.
>
> Tapestry also creates new properties based on the <property-specification>
> elements.
>
> After all this, it creates the class and checks that all inherited
abstract
> methods are implemented.
>
> And that's it ... its driven by whats in the specification, not anything
in
> the class.
>
> --
> hlship@attbi.com
>
> Creator, Tapestry: Java Web
> Components
> http://jakarta.apache.org/tapestry
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > This is a continuation from the thred : Upgrading to 2.4 alpha 5 (from
> > 2.2)
> >
> > Split because I'm now using and referring to 3.0, not 2.4.
> >
> > OK. I've been doing a bit of digging, and have a question:
> >
> > Q: Does the enhancer create methods ONLY for parameters that are listed
> > in the component specification? i.e: it does not attempt to create
> > implementations for "random abstract" methods.
> >
> > If so, then is a <reserved-parameter> counted in the "candidate
> > parameter" list?  In the cast of ValidatingTextField - there is no exact
> > 'value' parameter in the specification itself.  There IS an abstract
> > value accessor, which is inherited from the ValidField object however.
> >
> > So if it's not in the spec, and tapestry doesn't create an impl for it,
> > the enhancement validation will correctly fail.   Am I on the right
> > track, or have I taken a hike up a long twisty path?
> >
> > If this is the case, then does it mean that the enhancer "simply" has to
> > take into account the specifications of inherited objects, and add these
> > to the list of properties?  I'm guessing yes since the derived object is
> > going to inherit from ValidatingTextField, not ValidField$Enhanced_nn.
> >
> > My musings continue :-)
> >
> >
> >
> > - --
> > Regards,
> > Neil Clayton
> >
> > (PS: If you see strange text you don't understand underneath my email,
> > don't worry - it's just my PGP signature)
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.7 (GNU/Linux)
> >
> > iD4DBQE+26CmLXcfQF3yrNoRAnMTAJ9S2pNfhumWXtIBIWpPdR7Y8uNesACY4Z52
> > 6ecbeEUDWF8qODFEmZsauA==
> > =4M7M
> > -----END PGP SIGNATURE-----
> >
> >
> > ---------------------------------------------------------------------
> > 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

- --
Regards,
Neil Clayton

(PS: If you see strange text you don't understand underneath my email, don't
worry - it's just my PGP signature)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+3OWmLXcfQF3yrNoRArr4AKCbw88mn0xPr00J/4o8lJguGzKvDACggj85
qaDuGBGRyItWSCBS/vZsMxs=
=Y5Rf
-----END PGP SIGNATURE-----



----------------------------------------------------------------------------
----


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org



Mime
View raw message