[Fwd: Re: 3.1 Status / progress / thoughts]

[Pablo Lalloni <pl...@afip.gov.ar>]

Just forwarding Howard's answer 'cause I think it was meant for the
list.

-----Mensaje reenviado-----

> From: Howard Lewis Ship <hl...@gmail.com>
> To: Pablo Lalloni <pl...@afip.gov.ar>
> Subject: Re: 3.1 Status / progress / thoughts
> Date: Tue, 05 Oct 2004 19:39:20 -0400
> 
> Changing the attribute name to parameter is a possibility; it makes
> sense ... or naming the element <bind-parameter>.  Have to let that
> one settle a bit.
> 
> The prefix stays, however; one of the most common questions I get is
> (tediously) explaining to people where you use the prefix and where
> you don't.  Now there's nothing to explain.
> 
> <binding name="something"value="ognl: some.complex.expression + 'a
> string constant'"/>
> 
> or
> 
> <binding name="something">
>   ognl:
>        some.complex.expression + 'a string constant'
> </binding>
> 
> or however you want to format it.
> 
> 
> On Tue, 05 Oct 2004 19:56:54 -0300, Pablo Lalloni <pl...@afip.gov.ar> wrote:
> >  We use extensively the content of <binding/> to specify the ognl expression
> > since there you can use quotes freely... now how does this maps to the new
> > prefix syntax?
> >  
> >  This quotes thing qets specially important when we need to pass an OGNL
> > expressions as a strings to be evaluated later, which occurs often.
> >  
> >  I think separating the prefix from the expression would make it cleaner to
> > read & write:
> >  
> >  <binding name="something" type="ognl" value="some.complex.expression + 'a
> > string constant'"/>
> >  
> >  or
> >  
> >  <binding name="something" type="ognl">some.complex.expression + "a string
> > constant"</binding>
> >  
> >  Of course, "type" could have a sensitive default, honouring marc.f war cry.
> >  
> >  Also, while we're on the big move, why not grab the opportunity to rename
> > the "name" attribute to "parameter" since that's what it is IMHO.
> >  Newbies here doesn't associate quickly that "name" corresponds to a
> > parameter of the component being used, "name" seems like being just naming
> > the binding.
> >  
> >  So, we would have something like:
> >  
> >  <binding parameter="something" type="ognl" value="some.complex.expression +
> > 'a string constant'"/>
> >  
> >  or
> >  
> >  <binding parameter="something" type="ognl">some.complex.expression + "a
> > string constant"</binding>
> >  
> >  
> >  El mar, 05-10-2004 a las 14:30, Howard Lewis Ship escribió: 
> >  I'm just about ready to check in the first interesting changes for 3.1.
> > Just started introducing the 3.1 DTD. <inherited-binding>, <static-binding>,
> > <message-binding> have gone away (still valid if you use the 3.0 DTD).
> > <binding> is now <binding name="..." value="..."> or <binding name="...">
> > .... </binding> You now use prefixes in the spec exactly the same as in the
> > HTML template. Consistency! Example: <component id="loop" type="Foreach">
> > <binding name="source" value='ognl:items"/> <binding name="value"
> > value="ognl:item"/> <binding name="element" value="tr"/> </component>
> > <service> has gone away; you now need to do services from inside HiveMind.
> > 3.0 DTDs that use service will see a warning. So, you can see, that I'm
> > trying to simplify, streamline and improve consistency in the specs. One
> > thing I would like dearly to do is make a few broader changes: <property>
> > (3.0) --> <meta> (3.1) [[ for defining meta-data ]] <property-specification>
> > (3.0) --> <property> (3.1) [[ for adding properties to a class ]] I think
> > it's much neater, and if this was 1.0, there would be no question. But it's
> > 3.1 ... will this throw users too much? Perhaps we support both <property>
> > and <property-specification> in 3.1, as a transition towards <property>? 
> >  -- Pablo I. Lalloni Teléfono +54 (11) 4347-3177 Proyecto Pampa Dirección
> > Informática Tributaria AFIP
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Military intelligence is a contradiction in terms. -- Groucho Marx
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 

-- 

Pablo I. Lalloni 
Teléfono +54 (11) 4347-3177 
Proyecto Pampa
Dirección Informática Tributaria
AFIP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Open Standars, Open Documents, and Open Source"

  -- Scott Bradner (Open Sources, 1999 O'Reilly and Associates)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~