You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Eric Everman <ev...@precedadesign.com> on 2003/04/25 20:33:08 UTC
parameter vs property-specification
I believe I've been using these correctly, but certainly with a bit of
uncertainty. How are the semantics of <parameter> vs.
<property-specification> different for a component-specification?
Part of my confusion is the names - I would have assumed that parameters
would always be 'in', i.e. parameters. Properties would be the more
generic _properties_, possibly accessible in forms, yet it is the
*parameters* that have the form option. Also, is there a reason why one is
a "-specification" and the other not?
A related question: The documentation for <parameter> talks about some
distinctions for 'auto'. Why can auto only be used for required
parameters? How is a "synthetic wrapper property" different then a
"subclass that contains the implementation"?
Thanks for your help,
Eric Everman
Preceda Design LLC
www.precedadesign.com
Re: parameter vs property-specification
Posted by Geoff Longman <gl...@intelligentworks.com>.
Its not schema per se thats the problem. I'm sure that I could make the new
Spindle work with it. Its just that I finished my custom parser impl a while
ago and am knee deep in the project builder. Rather not revisit working code
and introduce more delay.
Like there hasn't been enough delay already!
And Howard.. Thanks for not making Components specless! I really mean it.
Specless pages are tough enough to separate from ordinary templates.
Geoff
----- Original Message -----
From: "Christian Sell" <ch...@netcologne.de>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Saturday, April 26, 2003 10:11 AM
Subject: Re: parameter vs property-specification
> when it comes to this, I can donate code that does schema caching, using
> Xerces 2.3 XNI
>
> Geoff Longman wrote:
> > Please do not shift to schema for 3.0. I'm caching parsed DTD grammars
and
> > I'd rather not revist that code.
> >
> > Geoff
> >
> > ----- Original Message -----
> > From: "Howard M. Lewis Ship" <hl...@attbi.com>
> > To: "'Tapestry users'" <ta...@jakarta.apache.org>
> > Sent: Friday, April 25, 2003 5:18 PM
> > Subject: RE: parameter vs property-specification
> >
> >
> > For each formal parameter, Tapestry will create a binding property:
> >
> > public void setXXXBinding(IBinding);
> > public IBinding getXXX();
> >
> > It will use an existing property if its already there, but I can't think
of
> > why you'd ever want to.
> >
> > In addition, for all directions EXCEPT "custom", Tapestry creates a
> > parameter property:
> >
> > public void setXXX(TYPE);
> > public TYPE getXXX();
> >
> > For "in" and "form", this is an ordinary property.
> > For "auto", this is a synthetic property that gets the binding and
invokes
> > getYYY() or setYYY() on it (YYY appropriate to type).
> >
> > About DTD element naming, which is far from perfect. As it is:
> > <property>
> > <parameter>
> > direction attribute
> > <property-specification>
> >
> > As it should be:
> > <meta-property>
> > <parameter>
> > connection attribute
> > <property>
> >
> > Woops; my precognition module was down when I created the DTD. I could
> > change from DTD to XML Schema, that would allow more flexibility, though
it
> > wouldn't help here (where <property> and <property-specification> can
appear
> > in all the same places).
> >
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/tapestry
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Eric Everman [mailto:everman@precedadesign.com]
> >>Sent: Friday, April 25, 2003 2:33 PM
> >>To: Tapestry users
> >>Subject: parameter vs property-specification
> >>
> >>
> >>I believe I've been using these correctly, but certainly with
> >>a bit of
> >>uncertainty. How are the semantics of <parameter> vs.
> >><property-specification> different for a component-specification?
> >>
> >>Part of my confusion is the names - I would have assumed that
> >>parameters
> >>would always be 'in', i.e. parameters. Properties would be the more
> >>generic _properties_, possibly accessible in forms, yet it is the
> >>*parameters* that have the form option. Also, is there a
> >>reason why one is
> >>a "-specification" and the other not?
> >>
> >>A related question: The documentation for <parameter> talks
> >>about some
> >>distinctions for 'auto'. Why can auto only be used for required
> >>parameters? How is a "synthetic wrapper property" different then a
> >>"subclass that contains the implementation"?
> >>
> >>Thanks for your help,
> >>
> >>Eric Everman
> >>
> >>Preceda Design LLC
> >>www.precedadesign.com
> >>
> >>
> >>---------------------------------------------------------------------
> >>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: parameter vs property-specification
Posted by Christian Sell <ch...@netcologne.de>.
when it comes to this, I can donate code that does schema caching, using
Xerces 2.3 XNI
Geoff Longman wrote:
> Please do not shift to schema for 3.0. I'm caching parsed DTD grammars and
> I'd rather not revist that code.
>
> Geoff
>
> ----- Original Message -----
> From: "Howard M. Lewis Ship" <hl...@attbi.com>
> To: "'Tapestry users'" <ta...@jakarta.apache.org>
> Sent: Friday, April 25, 2003 5:18 PM
> Subject: RE: parameter vs property-specification
>
>
> For each formal parameter, Tapestry will create a binding property:
>
> public void setXXXBinding(IBinding);
> public IBinding getXXX();
>
> It will use an existing property if its already there, but I can't think of
> why you'd ever want to.
>
> In addition, for all directions EXCEPT "custom", Tapestry creates a
> parameter property:
>
> public void setXXX(TYPE);
> public TYPE getXXX();
>
> For "in" and "form", this is an ordinary property.
> For "auto", this is a synthetic property that gets the binding and invokes
> getYYY() or setYYY() on it (YYY appropriate to type).
>
> About DTD element naming, which is far from perfect. As it is:
> <property>
> <parameter>
> direction attribute
> <property-specification>
>
> As it should be:
> <meta-property>
> <parameter>
> connection attribute
> <property>
>
> Woops; my precognition module was down when I created the DTD. I could
> change from DTD to XML Schema, that would allow more flexibility, though it
> wouldn't help here (where <property> and <property-specification> can appear
> in all the same places).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
>
>
>
>
>>-----Original Message-----
>>From: Eric Everman [mailto:everman@precedadesign.com]
>>Sent: Friday, April 25, 2003 2:33 PM
>>To: Tapestry users
>>Subject: parameter vs property-specification
>>
>>
>>I believe I've been using these correctly, but certainly with
>>a bit of
>>uncertainty. How are the semantics of <parameter> vs.
>><property-specification> different for a component-specification?
>>
>>Part of my confusion is the names - I would have assumed that
>>parameters
>>would always be 'in', i.e. parameters. Properties would be the more
>>generic _properties_, possibly accessible in forms, yet it is the
>>*parameters* that have the form option. Also, is there a
>>reason why one is
>>a "-specification" and the other not?
>>
>>A related question: The documentation for <parameter> talks
>>about some
>>distinctions for 'auto'. Why can auto only be used for required
>>parameters? How is a "synthetic wrapper property" different then a
>>"subclass that contains the implementation"?
>>
>>Thanks for your help,
>>
>>Eric Everman
>>
>>Preceda Design LLC
>>www.precedadesign.com
>>
>>
>>---------------------------------------------------------------------
>>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: parameter vs property-specification
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
No, that's blue sky talk. No intention of switching from DTD at this time.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Geoff Longman [mailto:glongman@intelligentworks.com]
> Sent: Saturday, April 26, 2003 6:42 AM
> To: Tapestry users
> Subject: Re: parameter vs property-specification
>
>
> Please do not shift to schema for 3.0. I'm caching parsed DTD
> grammars and I'd rather not revist that code.
>
> Geoff
>
> ----- Original Message -----
> From: "Howard M. Lewis Ship" <hl...@attbi.com>
> To: "'Tapestry users'" <ta...@jakarta.apache.org>
> Sent: Friday, April 25, 2003 5:18 PM
> Subject: RE: parameter vs property-specification
>
>
> For each formal parameter, Tapestry will create a binding property:
>
> public void setXXXBinding(IBinding);
> public IBinding getXXX();
>
> It will use an existing property if its already there, but I
> can't think of why you'd ever want to.
>
> In addition, for all directions EXCEPT "custom", Tapestry
> creates a parameter property:
>
> public void setXXX(TYPE);
> public TYPE getXXX();
>
> For "in" and "form", this is an ordinary property.
> For "auto", this is a synthetic property that gets the
> binding and invokes
> getYYY() or setYYY() on it (YYY appropriate to type).
>
> About DTD element naming, which is far from perfect. As it
> is: <property> <parameter> direction attribute
> <property-specification>
>
> As it should be:
> <meta-property>
> <parameter>
> connection attribute
> <property>
>
> Woops; my precognition module was down when I created the
> DTD. I could change from DTD to XML Schema, that would allow
> more flexibility, though it wouldn't help here (where
> <property> and <property-specification> can appear in all the
> same places).
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
>
>
>
> > -----Original Message-----
> > From: Eric Everman [mailto:everman@precedadesign.com]
> > Sent: Friday, April 25, 2003 2:33 PM
> > To: Tapestry users
> > Subject: parameter vs property-specification
> >
> >
> > I believe I've been using these correctly, but certainly
> with a bit of
> > uncertainty. How are the semantics of <parameter> vs.
> > <property-specification> different for a component-specification?
> >
> > Part of my confusion is the names - I would have assumed that
> > parameters would always be 'in', i.e. parameters.
> Properties would be
> > the more generic _properties_, possibly accessible in
> forms, yet it is
> > the
> > *parameters* that have the form option. Also, is there a
> reason why
> > one is a "-specification" and the other not?
> >
> > A related question: The documentation for <parameter> talks about
> > some distinctions for 'auto'. Why can auto only be used
> for required
> > parameters? How is a "synthetic wrapper property" different then a
> > "subclass that contains the implementation"?
> >
> > Thanks for your help,
> >
> > Eric Everman
> >
> > Preceda Design LLC
> > www.precedadesign.com
> >
> >
> >
> ---------------------------------------------------------------------
> > 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: parameter vs property-specification
Posted by Geoff Longman <gl...@intelligentworks.com>.
Please do not shift to schema for 3.0. I'm caching parsed DTD grammars and
I'd rather not revist that code.
Geoff
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@attbi.com>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Friday, April 25, 2003 5:18 PM
Subject: RE: parameter vs property-specification
For each formal parameter, Tapestry will create a binding property:
public void setXXXBinding(IBinding);
public IBinding getXXX();
It will use an existing property if its already there, but I can't think of
why you'd ever want to.
In addition, for all directions EXCEPT "custom", Tapestry creates a
parameter property:
public void setXXX(TYPE);
public TYPE getXXX();
For "in" and "form", this is an ordinary property.
For "auto", this is a synthetic property that gets the binding and invokes
getYYY() or setYYY() on it (YYY appropriate to type).
About DTD element naming, which is far from perfect. As it is:
<property>
<parameter>
direction attribute
<property-specification>
As it should be:
<meta-property>
<parameter>
connection attribute
<property>
Woops; my precognition module was down when I created the DTD. I could
change from DTD to XML Schema, that would allow more flexibility, though it
wouldn't help here (where <property> and <property-specification> can appear
in all the same places).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Eric Everman [mailto:everman@precedadesign.com]
> Sent: Friday, April 25, 2003 2:33 PM
> To: Tapestry users
> Subject: parameter vs property-specification
>
>
> I believe I've been using these correctly, but certainly with
> a bit of
> uncertainty. How are the semantics of <parameter> vs.
> <property-specification> different for a component-specification?
>
> Part of my confusion is the names - I would have assumed that
> parameters
> would always be 'in', i.e. parameters. Properties would be the more
> generic _properties_, possibly accessible in forms, yet it is the
> *parameters* that have the form option. Also, is there a
> reason why one is
> a "-specification" and the other not?
>
> A related question: The documentation for <parameter> talks
> about some
> distinctions for 'auto'. Why can auto only be used for required
> parameters? How is a "synthetic wrapper property" different then a
> "subclass that contains the implementation"?
>
> Thanks for your help,
>
> Eric Everman
>
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> 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: parameter vs property-specification
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
For each formal parameter, Tapestry will create a binding property:
public void setXXXBinding(IBinding);
public IBinding getXXX();
It will use an existing property if its already there, but I can't think of
why you'd ever want to.
In addition, for all directions EXCEPT "custom", Tapestry creates a
parameter property:
public void setXXX(TYPE);
public TYPE getXXX();
For "in" and "form", this is an ordinary property.
For "auto", this is a synthetic property that gets the binding and invokes
getYYY() or setYYY() on it (YYY appropriate to type).
About DTD element naming, which is far from perfect. As it is:
<property>
<parameter>
direction attribute
<property-specification>
As it should be:
<meta-property>
<parameter>
connection attribute
<property>
Woops; my precognition module was down when I created the DTD. I could
change from DTD to XML Schema, that would allow more flexibility, though it
wouldn't help here (where <property> and <property-specification> can appear
in all the same places).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Eric Everman [mailto:everman@precedadesign.com]
> Sent: Friday, April 25, 2003 2:33 PM
> To: Tapestry users
> Subject: parameter vs property-specification
>
>
> I believe I've been using these correctly, but certainly with
> a bit of
> uncertainty. How are the semantics of <parameter> vs.
> <property-specification> different for a component-specification?
>
> Part of my confusion is the names - I would have assumed that
> parameters
> would always be 'in', i.e. parameters. Properties would be the more
> generic _properties_, possibly accessible in forms, yet it is the
> *parameters* that have the form option. Also, is there a
> reason why one is
> a "-specification" and the other not?
>
> A related question: The documentation for <parameter> talks
> about some
> distinctions for 'auto'. Why can auto only be used for required
> parameters? How is a "synthetic wrapper property" different then a
> "subclass that contains the implementation"?
>
> Thanks for your help,
>
> Eric Everman
>
> Preceda Design LLC
> www.precedadesign.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>