Thanks both for your answers! They were helpful. I guess my angle was more
from an older ASP web application paradigm or even old style PHP which
didn't have much distinction with models, views, and controllers. My only
question/complaint about the jumping back and forth between the template and
Page class is what do you do when you want to do different things based on
something like an enum instead of simply a boolean? Would you have to have
multiple boolean functions one for each possible enum value that you wish to
test?
For example, if I have (using a credit card theme here) an enum for a
transaction status with values of DECLINED and ACCEPTED, if I want to
display ACCEPTED in green and DECLINED in red, would I have to have two
functions isDeclined and isAccepted and do an t:if to control red and green
display? Sometimes here, I feel, is where having scripting capability helps
in the display of the page to prevent a page class with a ton of simple
getter methods.
Also can you explain what this does?
@Parameter(required=true)
private String ccNumber
Thanks again and I'm excited to continue using Tapestry!
- Amit
On Fri, Mar 20, 2009 at 6:10 AM, Christian Edward Gruber <
christianedwardgru...@gmail.com> wrote:
> Thiago, I think he's misunderstanding the point of Tapestry. You never do
> scripting in the views. In fact, you never do scripting. Scripting (in web
> templates) mixes display layout and display flow with business logic, data
> flow, and user workflow. They're all mixed up together. Anyone used to
> that will have a hard time seeing how to accomplish the same features in
> their application without access to any ability to embed scripted code into
> the view.
>
> Amit, you need to re-think your orientation when using something like
> Tapestry. All of your code is in controllers, with the exception of some
> display layout flows like loops, conditionals, and such. There are
> components for these, but unlike JSP tags, they do not "unwind" into code,
> they are components and all the pages are composed, with a rendering engine
> that asks components to render themselves or their templates, and their
> child components, who are in turn asked to render. It's a very different
> paradigm.
>
> In practice though, if you're thinking of having a lot of logic you would
> imagine going into scriptlets or the like, factor that code into methods
> which return the displayable result. For instance (this code is made up on
> the spot):
>
> <%
> CreditCard cc =
> myDao.getCreditCardByNumber(request.getProperty("ccNumber"));
> %>
> <h2><%=cc.getType().getName()%> card</h2>
> <p>Card <%=cc.getNumber()%> has the following purchases today:<p>
> <table><tr><th>Date</th><th>Vendor</th><th>Amount</th><th>Posted?</th></tr>
> <%
> List<CCTransaction> txns =
> myDao.getTransactionsForCC(cc.getNumber());
> for (CCTransaction txn: txns) { %>
> <tr>
> <td><%=MyUtil.format(txn.getDate())%></td>
> <td><%=txn.getVendor()%></td>
> <td><%=MyUtil.formatCurrency(txn.getAmount(),"USD")%></td>
> <td><%=txn.isPosted()%></td>
> </tr>
> <% } %>
>
>
> The above is pretty ugly JSP code, and even with Struts or other web MVC
> frameworks that use JSPs as a base, it can be that ugly. Tapestry goes a
> different way. (this code was also cooked up at 8am after a red-eye
> flight... it is uncompiled, let alone untested. Don't cut-and-paste it.
> This example uses credit card, but doesn't authenticate and is massively
> insecure. It's only paying attention to a certain aspect of things.)
>
> MyPage.java
> ...
> public class MyPage {
>
> @Inject
> private MyDao myDao;
>
> @Property
> private CCTransaction currentTransaction;
>
> @Parameter(required=true)
> private String ccNumber;
>
> @Property
> private CreditCard creditCard;
>
> @SetupRender
> public void init() {
> //do validation stuff...
> creditCard = myDao.getCreditCardByNumber(ccNumber);
> }
>
> public List<CCTransaction> getTransactions() {
>
> }
>
> }
>
> MyPage.tml
> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
> .....
> <h2>${creditCard.type} card</h2>
> <p>Card ${creditCard.number} has the following purchases today:<p>
>
> <table>
> <tr><th>Date</th><th>Vendor</th><th>Amount</th><th>Posted?</th></tr>
> <tr t:id="layout" source="transactions" value="currentTransaction">
> <td><t:output t:format="YY:MM:DD HH:mm"
> t:value="currentTransaction.date"/></td>
> <td>${currentTransaction.getVendor}</td>
> <td>USD ${currentTransaction.amount}></td>
> <td>${currentTransaction.isPosted}</td>
> </tr>
> </table>
>
> The display logic and flow control is in the template, but no actual data
> lookups or business calculations. I don't know if it helps, but hopefully
> it gives you a taste of how things are different.
>
> On this note, it might be good to have some side-by-side mini-examples
> which show how someone would do something in vanilla JSP, in Struts, in JSF,
> and in Tapestry so people can make the mental leap. Annoying to build, I
> know, but potentially highly useful.
>
> regards,
> Christian.
>
>
>
> On 20-Mar-09, at 08:07 , Thiago H. de Paula Figueiredo wrote:
>
> On Fri, Mar 20, 2009 at 1:53 AM, Amit Nithian <anith...@gmail.com> wrote:
>>
>>> 1) With Tapestry, I understand the Controller is effectively the Page and
>>> Components with the View being the template files. I haven't seen any
>>> examples of complex "scripting" in the templates where you can build
>>> complex
>>> views.
>>>
>>
>> Please give us an example. Your description is a vague enough for me
>> to not understand what you're talking about.
>>
>> How do people build nice looking, complex front ends with Tapestry
>>> backends?
>>>
>>
>> Again, I don't know exactly what you're talking about. Anything you
>> can do with HTML, CSS and JavaScript you can do with Tapestry.
>> Tapestry deals with the server side of things, but also helps with
>> some JavaScript issues, specially AJAX.
>>
>> --
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
> Christian Edward Gruber
> e-mail: christianedwardgru...@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
