Trails 1.2 & OGNL issues

Hi All

I've been testing Trails 1.2 for a while (over two months) now, and
OGNL is giving me a huge headache.
Every thing was fine while the application was just Trails without
customizations, but when I started to grow the application, when I
stared to mix Trails pages and components with plain Tapestry pages, I
got an avalanche of OGNL exceptions.

Examples:
1) my domain model has two subsets, the core business domain model and
the identity management model. The identity management model is shared
by several application so I can't change its code.
I wanted the default page navigation to be list -> view -> edit, so I
added this simple @Block to my DefaultList page:

          <div jwcid="idColumnValue@Block">
                  <a jwcid="viewLink@trails:ViewLink" model="ognl:object"
href="#"><span jwcid="@Insert" value="ognl:object.id"/></a>
          </div>

As simple as it looks this code fails throwing a beautiful
ClassCastException if all the entity's IDs aren't of the same type.

2)

Let's say you want to save some typing and you add a nice default
value to your component parameters, like:

        @Parameter(required = false, defaultValue = "page.classDescriptor",
cache = true)
        public abstract IClassDescriptor getClassDescriptor();

This code will throw another ClassCastException if all the pages from
where it is been used do not share a common ancestor with the
getClassDescriptor method.

3)
The same thing happens for this code:

        @Parameter(defaultValue = "container.model")
        public abstract Object getModel();

This code was meant to be used indifferently from a Page or from a
Component, but it fails if the components and pages do not share a
common ancestor containing the getModel method. This means that
components like the PropertyEditor can't be used from inside another
component without explicitly setting all its parameters.


Although there are workarounds for all of them and they seem like not
so big a deal, they are huge when you depend on Trails development
speed and you have to spent most of your time working around these
issues.

On this particular project we are planning to move to T5 asap, but I
wonder what to do with the Trails 1.2 release.

What should we do?

We can't revert back to OGNL 2.6.x.
We can't use tapestry-prop.
We could remove all the "defaultValue"s and we could declare
interfaces for every known property (eg: classDescriptor,
propertyDescriptor, model, modelNew, blockFinder) but that's way too
verbose.
We could disable caching (org.apache.tapestry.disable-caching=true)
but that will not perform well at all.
We could wait until OGNL enables a "don't ever compile" option.
We could release 1.2 anyway

I'm open ears. What do you think?

BTW, here is a old and long thread about this ognl feature:
http://www.mail-archive.com/users@.../msg15191.html


Saludos.
Alejandro.


--
Alejandro Scandroli - http://weblog.amneris.es/
Amneris: We build process-driven web applications.
http://www.amneris.es

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email