RE: [jira] Created: (TAPESTRY-331) Simplified insert binding temp late syntax

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [jira] Created: (TAPESTRY-331) Simplified insert binding temp late syntax

richard.hensley
Yes, please!!! +1

Us programmer types that have to build html also hate typing...

I would say that some rules and a name are in order, for instance:

First for a name, I don't have any good ideas, so I will call the tapestry
expressions for this e-mail.

Now for a shot at some rules about where Tapestry Expressions can occur,
following the keep it strict until use cases dictate otherwise, I would
restrict the use to the following.

1. A tapestry expression can occur as part of the body of an element.
2. A tapestry expression can occur as whole of the right hand side of an
attribute assignment.
3. A tapestry expression can not appear anywhere else.

I think the legal syntax is the "normal" tapestry value setting syntax. It
defaults to a ognl: prefix when one is not present.

My only heartburn about this whole thing is that it allows easy violation of
a core Tapestry feature which is that Designer tools work with the
templates.

Richard

-----Original Message-----
From: Erik Hatcher [mailto:[hidden email]]
Sent: Friday, May 13, 2005 5:49 PM
To: Tapestry development
Subject: Re: [jira] Created: (TAPESTRY-331) Simplified insert binding
template syntax

Huge +1!!!  I'll reply in more detail when I can.

     Erik


On May 13, 2005, at 4:55 PM, Howard M. Lewis Ship (JIRA) wrote:

> Simplified insert binding template syntax
> -----------------------------------------
>
>          Key: TAPESTRY-331
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-331
>      Project: Tapestry
>         Type: New Feature
>   Components: Framework
>     Versions: 4.0
>     Reporter: Howard M. Lewis Ship
>     Priority: Minor
>      Fix For: 4.0
>
>
> It would be desirable to support a simplified syntax for obtaining  
> data via bindings and inserting it.  A proposal has been to adopt  
> ant-like syntax ("${...}") and interpret the expression within the  
> braces as a binding reference.  This would eliminate the need for  
> many Insert components, i.e.:
>
>
> <h1>${thread.title}</h1>
>
> rather than:
>
> <h1><span jwcid="@Insert" value="thread.title"/></h1>
>
> Or:
>
> ${message:prompt}
>
> rather than:
>
> <span key="prompt"/>
>
>
> This kind of substitution is less invisible, but generally less  
> intrusive, than creating a new component.
>
> Further, the use of the Any component could be reduced via support  
> for:
>
> <img src="${imagePath}"/>
>
> rather than:
>
> <img jwcid="@Any" src="ognl:imagePath"/>
>
>
> Some questions occur; are the following legal?
>
> <${element}> ... </${element}>
> <img jwcid="@Image" src="${asset:foo}"/>
> <div ${attribute}="${value}"/>
>
>
> A final note: these bindings should be treated as we treat informal  
> parameters today; this includes automatically expanding IAssets  
> into their corresponding URLs.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the  
> administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira
>
>
> ---------------------------------------------------------------------
> 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]


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

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Created: (TAPESTRY-331) Simplified insert binding temp late syntax

Nathan Kopp

"Hensley, Richard" <[hidden email]> wrote...
> Yes, please!!! +1
>

I, of course, would certainly vote for this if I had a binding vote.  I
actually currently run a customized version of Tapestry 3.0 that implements
this exact feature.  So I would of course love to see this in the official
version so I don't have to reimplement it when I move to 4.0.  :-)

> My only heartburn about this whole thing is that it allows easy violation
of
> a core Tapestry feature which is that Designer tools work with the
> templates.

In my experience, it doesn't make things any worse than they are.  Sure,
when you're working with a normal HTML editor, you'll see some messiness
(the expressions) when you preview the template.  Oh, well... the Insert
component could still be used by people who want prettier previews.
Personally, I like seeing the expressions when I preview a template.

When used as an attribute value, it's no worse than what we have now.  HTML
design tools will balk just as much when they see "ognl:expression" as an
attribute value as when they see "${expression}" as a value for an attribute
where a number is expected.

-Nathan


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

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Created: (TAPESTRY-331) Simplified insert binding temp late syntax

Robert Zeigler-2
In reply to this post by richard.hensley
Hensley, Richard wrote:

> Yes, please!!! +1
>
> Us programmer types that have to build html also hate typing...
>
> I would say that some rules and a name are in order, for instance:
>
> First for a name, I don't have any good ideas, so I will call the tapestry
> expressions for this e-mail.
>
> Now for a shot at some rules about where Tapestry Expressions can occur,
> following the keep it strict until use cases dictate otherwise, I would
> restrict the use to the following.
>
> 1. A tapestry expression can occur as part of the body of an element.
> 2. A tapestry expression can occur as whole of the right hand side of an
> attribute assignment.
> 3. A tapestry expression can not appear anywhere else.

Hm. what about inside comments?
This would be really useful for javascript. :)
I realize that I can create a .script file, etc., etc., etc.
But, sometimes (oftentimes? =) That's an awful lot of work for
some very simple stuff. So, for example..
<script>
<!--
function confirmSomething() {
        var msg = ${message:prompt_message};
        return confirm(msg);
}
-->
</script>
Since js blocks are usually enclosed in comments...
Just a thought. :)

Robert

>
> I think the legal syntax is the "normal" tapestry value setting syntax. It
> defaults to a ognl: prefix when one is not present.
>
> My only heartburn about this whole thing is that it allows easy violation of
> a core Tapestry feature which is that Designer tools work with the
> templates.
>
> Richard
>
> -----Original Message-----
> From: Erik Hatcher [mailto:[hidden email]]
> Sent: Friday, May 13, 2005 5:49 PM
> To: Tapestry development
> Subject: Re: [jira] Created: (TAPESTRY-331) Simplified insert binding
> template syntax
>
> Huge +1!!!  I'll reply in more detail when I can.
>
>      Erik
>
>
> On May 13, 2005, at 4:55 PM, Howard M. Lewis Ship (JIRA) wrote:
>
>
>>Simplified insert binding template syntax
>>-----------------------------------------
>>
>>         Key: TAPESTRY-331
>>         URL: http://issues.apache.org/jira/browse/TAPESTRY-331
>>     Project: Tapestry
>>        Type: New Feature
>>  Components: Framework
>>    Versions: 4.0
>>    Reporter: Howard M. Lewis Ship
>>    Priority: Minor
>>     Fix For: 4.0
>>
>>
>>It would be desirable to support a simplified syntax for obtaining  
>>data via bindings and inserting it.  A proposal has been to adopt  
>>ant-like syntax ("${...}") and interpret the expression within the  
>>braces as a binding reference.  This would eliminate the need for  
>>many Insert components, i.e.:
>>
>>
>><h1>${thread.title}</h1>
>>
>>rather than:
>>
>><h1><span jwcid="@Insert" value="thread.title"/></h1>
>>
>>Or:
>>
>>${message:prompt}
>>
>>rather than:
>>
>><span key="prompt"/>
>>
>>
>>This kind of substitution is less invisible, but generally less  
>>intrusive, than creating a new component.
>>
>>Further, the use of the Any component could be reduced via support  
>>for:
>>
>><img src="${imagePath}"/>
>>
>>rather than:
>>
>><img jwcid="@Any" src="ognl:imagePath"/>
>>
>>
>>Some questions occur; are the following legal?
>>
>><${element}> ... </${element}>
>><img jwcid="@Image" src="${asset:foo}"/>
>><div ${attribute}="${value}"/>
>>
>>
>>A final note: these bindings should be treated as we treat informal  
>>parameters today; this includes automatically expanding IAssets  
>>into their corresponding URLs.
>>
>>--
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the  
>>administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
>>
>>---------------------------------------------------------------------
>>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]
>
>
> ---------------------------------------------------------------------
> 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]