You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Neil Clayton <ne...@cloudnine.net.nz> on 2003/06/02 21:08:20 UTC

Upgrading to 3.0 (cvs HEAD) from 2.2

-----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-----