tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Le Bas <m...@nlebas.net>
Subject Re: Pull Request #4: Object-Type Attribute Value Evaluation
Date Wed, 15 Jul 2015 01:53:22 GMT
Hi all,

First of all, I take responsibility for cross posting to the dev list.
Sorry if it surprised you, Brett, I just feel it is a better place to
discuss code changes. People come here with a different mindset.

And sorry for the delay in my answer, too. We're all volunteers here :)
As a consequence, it will be a long answer, and I feel like apologizing
again.


Concerning a universal solution to Brett's problem: well, here's what
I've been doing for the past years. I do not pretend it is better, just
that I like it:


I find, like Brett, that the "JavaBeans" tags from struts-tiles (item
and bean) are limited in nature. In my experience I only encountered two
situtations were they were useful, and in both situations I've found
other solutions to be more effective and maintainable.


1. The static approach
I like the pure HTML+CSS solution to this: <ul><li>My Account</li><li>My
Orders</li></ul>. It looks and lives well within the template itself.

2. The dynamic list.
In most cases, I find it more convenient to add a bean into the
appropriate context through the application. For instance, with spring:

<util:list id="breadcrumbsData">
   <bean class="example.Link" p:value="#{customer.id}"
p:link="/customers/#{customer.id}" />
   <bean class="example.Link" p:value="Orders"
p:link="/customers/#{customer.id}/salesOrders" />
   <bean class="example.Link" p:value="#{order.id}"
p:link="/customers/#{customer.id}/salesOrders/#{order.id}" />
</util:list>

And then in tiles:
    <put-attribute name="breadcrumbs" expression="${breadcrumbsData}"/>

I find this "breadcrumbsData" tends to evolve over the life of the
application into something more and more dynamic, for instance session
specific or requires a data model more complex than the <item>-type of
thing. Sometimes it is also more convenient to create the list by hand
and add it to the session/servlet context programatically.


I used the tiles-centric solution back at the time when CSS and DI were
barely budding, and their long-term adoption was still questionable, but
now I prefer other ways. That being said, I'm totally open to
contributions that would be useful to others.




Concerning the documentation: I totally agree it needs work, there's a
ramp up to learning Tiles 3. Initialization is cumbersome, and as we
discussed earlier, the duality between "value" and "expression" is
confusing. All of this is documented on the website, but the docs are
dry and learning is difficult. Perhaps we could rework the tutorials and
update the examples. Another dark area is: how to test?

That being said, my time being limited, I prefer to invest it in
simplifying the usage of tiles before documenting the simple solution,
as opposed to trying to explain the complex solution in a clear way.

So personnally I'm looking at reviewing the docs when tiles can be
configured from DI, and run in junit (tiles 3.1, perhaps. My github fork
already has the junit part working, and I'm experimenting with DI).

Cheers!

Nick

PS: On 15-07-08 09:21 AM, Brett Ryan wrote:
> toString should always be a string representation of a value, not
null, alternatives would be "null" or "(null)".

+1, definitely






Mime
View raw message