[DISCUSS] Default binding prefixes

[pferraro]

I would like to discuss 2 issues relating to binding prefixes:
1.  In alpha-1 (or maybe earlier), I recall that the default binding
prefix for bean properties was changed to "literal".  I saw this as an
improvement over 3.1.  In alpha-2, this was changed back to "ognl".
I think I liked it better the other way around.  I dislike having to use
nested quotes to define literal strings this way within an xml attribute
(e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
Can we switch this back?

2.  The more I use 4.0, the more I find the default binding prefix
override for component parameters to be incredibly frustrating.  I think
that the hassle of having to lookup (or remember) the expected binding
prefix for each component parameter far outweighs the minimal keystroke
savings.  I liked it better when "literal" was the default and
overriding was not permitted.   Things were much more straight forward
that way.  I find that I am wasting a lot of time debugging runtime
exceptions in my component specification because I assumed the wrong
binding prefix.

Thoughts?

Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brian K. Wallace]

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

To point 1:
I noticed this change as well and I must say I agree that the literal
should take precedence. I understand that "if you use non-literal, it's
probably ognl", but that can tend to be a big 'if'. And to be honest -
if it's enclosed in quotes, it appears as though you should be able to
accept it as a string, not an expression.

What I would propose - and it impacts configuration code more than
anything - is the following:
~  1. Literal is the default
~  2. Configuration can override the default

What I mean by this is - with 0 changes to any configuration anywhere -
if you type <set name="pattern" value="MM-dd-yyyy"/>, that's what you
get - literal - as it's the default. If you go into your configuration,
however, you can specify (possibly via a service?)
default-binding="ognl", default-binding="???" - let the 'default' be the
user's to decide. A related change would be to allow configuration of
what prefix is mapped to which binding - specify 'o' for 'ognl', but
that's outside the scope of what you brought up (and might prove
cumbersome for utilizing outside component libraries).

For point 2 I have no thoughts either way, but do understand the extra
work.

Brian

Paul Ferraro wrote:
| I would like to discuss 2 issues relating to binding prefixes:
| 1.  In alpha-1 (or maybe earlier), I recall that the default binding
| prefix for bean properties was changed to "literal".  I saw this as an
| improvement over 3.1.  In alpha-2, this was changed back to "ognl".
| I think I liked it better the other way around.  I dislike having to use
| nested quotes to define literal strings this way within an xml attribute
| (e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
| Can we switch this back?
|
| 2.  The more I use 4.0, the more I find the default binding prefix
| override for component parameters to be incredibly frustrating.  I think
| that the hassle of having to lookup (or remember) the expected binding
| prefix for each component parameter far outweighs the minimal keystroke
| savings.  I liked it better when "literal" was the default and
| overriding was not permitted.   Things were much more straight forward
| that way.  I find that I am wasting a lot of time debugging runtime
| exceptions in my component specification because I assumed the wrong
| binding prefix.
|
| Thoughts?
|
| Paul
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: [hidden email]
| For additional commands, e-mail: [hidden email]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCexTQaCoPKRow/gARAoUaAKDk3kI+rx3Xc3Wj5ANueQg8GM2LXQCfdmEi
6DsUk2xrwLgbqxqMHJKvQkw=
=PWwT
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Vjeran Marcinko]

+1 from me about this Paul's notes.

I know that Erik will be disappointed, but default binding prefixes seems
more as complication than simplification, at least by me (and Paul
obviously).
I think that it's enough for users to have to know Tapestry's binding
prefixes, and type of parameter, and now they even have to look at component
specs for parameter's default prefix to know what this value without prefix
means.

Just my 2 cents.

-Vjeran

----- Original Message -----
From: "Paul Ferraro" <[hidden email]>
Newsgroups: gmane.comp.jakarta.tapestry.devel
Sent: Friday, May 06, 2005 8:01 AM
Subject: [DISCUSS] Default binding prefixes

> I would like to discuss 2 issues relating to binding prefixes:
> 1.  In alpha-1 (or maybe earlier), I recall that the default binding
> prefix for bean properties was changed to "literal".  I saw this as an
> improvement over 3.1.  In alpha-2, this was changed back to "ognl".
> I think I liked it better the other way around.  I dislike having to use
> nested quotes to define literal strings this way within an xml attribute
> (e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
> Can we switch this back?
>
> 2.  The more I use 4.0, the more I find the default binding prefix
> override for component parameters to be incredibly frustrating.  I think
> that the hassle of having to lookup (or remember) the expected binding
> prefix for each component parameter far outweighs the minimal keystroke
> savings.  I liked it better when "literal" was the default and
> overriding was not permitted.   Things were much more straight forward
> that way.  I find that I am wasting a lot of time debugging runtime
> exceptions in my component specification because I assumed the wrong
> binding prefix.
>
> Thoughts?

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 4.5.2005


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Howard Lewis Ship]

About the beans:  Have to think on that one.

About the parameters:  It is still an experiment, but I'm liking what
I see.  If you are confused, use a prefix (even if it matches the
default-binding).  As you use 4.0 more and more, you'll see the
obvious places where you don't need a binding prefix and you can start
to not use them.

On 5/6/05, Vjeran Marcinko <[hidden email]> wrote:

> +1 from me about this Paul's notes.
>
> I know that Erik will be disappointed, but default binding prefixes seems
> more as complication than simplification, at least by me (and Paul
> obviously).
> I think that it's enough for users to have to know Tapestry's binding
> prefixes, and type of parameter, and now they even have to look at component
> specs for parameter's default prefix to know what this value without prefix
> means.
>
> Just my 2 cents.
>
> -Vjeran
>
> ----- Original Message -----
> From: "Paul Ferraro" <[hidden email]>
> Newsgroups: gmane.comp.jakarta.tapestry.devel
> Sent: Friday, May 06, 2005 8:01 AM
> Subject: [DISCUSS] Default binding prefixes
>
> > I would like to discuss 2 issues relating to binding prefixes:
> > 1.  In alpha-1 (or maybe earlier), I recall that the default binding
> > prefix for bean properties was changed to "literal".  I saw this as an
> > improvement over 3.1.  In alpha-2, this was changed back to "ognl".
> > I think I liked it better the other way around.  I dislike having to use
> > nested quotes to define literal strings this way within an xml attribute
> > (e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
> > Can we switch this back?
> >
> > 2.  The more I use 4.0, the more I find the default binding prefix
> > override for component parameters to be incredibly frustrating.  I think
> > that the hassle of having to lookup (or remember) the expected binding
> > prefix for each component parameter far outweighs the minimal keystroke
> > savings.  I liked it better when "literal" was the default and
> > overriding was not permitted.   Things were much more straight forward
> > that way.  I find that I am wasting a lot of time debugging runtime
> > exceptions in my component specification because I assumed the wrong
> > binding prefix.
> >
> > Thoughts?
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 4.5.2005
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Harish Krishnaswamy]

I actually do like the default prefixes the way it is now, but if more
and more people start to have problems with it, yes you can always
specify the prefix but it can, more conveniently, be made configurable
like Brian suggests.

-Harish

On 5/6/05, Howard Lewis Ship <[hidden email]> wrote:

> About the beans:  Have to think on that one.
>
> About the parameters:  It is still an experiment, but I'm liking what
> I see.  If you are confused, use a prefix (even if it matches the
> default-binding).  As you use 4.0 more and more, you'll see the
> obvious places where you don't need a binding prefix and you can start
> to not use them.
>
> On 5/6/05, Vjeran Marcinko <[hidden email]> wrote:
> > +1 from me about this Paul's notes.
> >
> > I know that Erik will be disappointed, but default binding prefixes seems
> > more as complication than simplification, at least by me (and Paul
> > obviously).
> > I think that it's enough for users to have to know Tapestry's binding
> > prefixes, and type of parameter, and now they even have to look at component
> > specs for parameter's default prefix to know what this value without prefix
> > means.
> >
> > Just my 2 cents.
> >
> > -Vjeran
> >
> > ----- Original Message -----
> > From: "Paul Ferraro" <[hidden email]>
> > Newsgroups: gmane.comp.jakarta.tapestry.devel
> > Sent: Friday, May 06, 2005 8:01 AM
> > Subject: [DISCUSS] Default binding prefixes
> >
> > > I would like to discuss 2 issues relating to binding prefixes:
> > > 1.  In alpha-1 (or maybe earlier), I recall that the default binding
> > > prefix for bean properties was changed to "literal".  I saw this as an
> > > improvement over 3.1.  In alpha-2, this was changed back to "ognl".
> > > I think I liked it better the other way around.  I dislike having to use
> > > nested quotes to define literal strings this way within an xml attribute
> > > (e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
> > > Can we switch this back?
> > >
> > > 2.  The more I use 4.0, the more I find the default binding prefix
> > > override for component parameters to be incredibly frustrating.  I think
> > > that the hassle of having to lookup (or remember) the expected binding
> > > prefix for each component parameter far outweighs the minimal keystroke
> > > savings.  I liked it better when "literal" was the default and
> > > overriding was not permitted.   Things were much more straight forward
> > > that way.  I find that I am wasting a lot of time debugging runtime
> > > exceptions in my component specification because I assumed the wrong
> > > binding prefix.
> > >
> > > Thoughts?
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 4.5.2005
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Henri Dupre]

>
> I find that I am wasting a lot of time debugging runtime
> exceptions in my component specification because I assumed the wrong
> binding prefix.



Maybe I'm a little unrealistic but are there any chances to see a testing
environment for parsing component and page specs? Something that would
prevent to have to redeploy the app everytime and run the pages?
It'd be so cool to be able to really "load" the pages inside test units.

Henri.

[Erik Hatcher]

On May 6, 2005, at 9:09 AM, Vjeran Marcinko wrote:

> +1 from me about this Paul's notes.
>
> I know that Erik will be disappointed, but default binding prefixes  
> seems
> more as complication than simplification, at least by me (and Paul
> obviously).
> I think that it's enough for users to have to know Tapestry's binding
> prefixes, and type of parameter, and now they even have to look at  
> component
> specs for parameter's default prefix to know what this value  
> without prefix
> means.

I'm not going to be disappointed either way.  I'm after simplicity in  
what it takes for me to build a page and to look at it.  Seeing  
listener="listener:...." looks very silly.  But I do concur that it  
is confusing to have to know what the binding prefixes are - though  
in practice the defaults should be what is generally used anyway,  
with prefixes only needed when you break out of the norm.

     Erik

>
> Just my 2 cents.
>
> -Vjeran
>
> ----- Original Message -----
> From: "Paul Ferraro" <[hidden email]>
> Newsgroups: gmane.comp.jakarta.tapestry.devel
> Sent: Friday, May 06, 2005 8:01 AM
> Subject: [DISCUSS] Default binding prefixes
>
>
>
>> I would like to discuss 2 issues relating to binding prefixes:
>> 1.  In alpha-1 (or maybe earlier), I recall that the default binding
>> prefix for bean properties was changed to "literal".  I saw this  
>> as an
>> improvement over 3.1.  In alpha-2, this was changed back to "ognl".
>> I think I liked it better the other way around.  I dislike having  
>> to use
>> nested quotes to define literal strings this way within an xml  
>> attribute
>> (e.g. <set name="pattern" value="'MM-dd-yyyy'"/>).
>> Can we switch this back?
>>
>> 2.  The more I use 4.0, the more I find the default binding prefix
>> override for component parameters to be incredibly frustrating.  I  
>> think
>> that the hassle of having to lookup (or remember) the expected  
>> binding
>> prefix for each component parameter far outweighs the minimal  
>> keystroke
>> savings.  I liked it better when "literal" was the default and
>> overriding was not permitted.   Things were much more straight  
>> forward
>> that way.  I find that I am wasting a lot of time debugging runtime
>> exceptions in my component specification because I assumed the wrong
>> binding prefix.
>>
>> Thoughts?
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 4.5.2005
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]