I would tend to agree with this, but the real issue is striking a
balance between flexibility and simplicity. I know the Richclient uses
the same skinning mechanism as Trinidad (it USES Trinidad Skinning) and
the look and feels out of that renderkit are entirely different. With a
less flexible system, that kind of capability would not be possible.
<shrug> Maybe better things can be done to strike a balance, but in our
projects, the flexibility on the skinning has helped us more then it has
hurt us.
Scott
Werner Punz wrote:
Simon Lessard schrieb:
Hi,
The UIX issue is a very valid one indeed and so few link to it
remains, it's a shame that we didn't get rid of it already and I'm to
blame a lot for that because I started it a long time ago but was
never able to finish it.
However, as Matthias pointed out, JSF 2.0 standardize Trinidad's
principal core features namely PPR and Resource handling and
hopefully skinning too. Under such circumstances, I feel that we
should wait for 2.0 to be cemented before going through a massive
refactoring of some of the old and twisted code parts so that the
refactored design is fully compatible with 1.2, but using 2.0 concept
to make the upgrade to 2.0 easier imho.
Actually regarding skinning, I have used Trinidad at a customer and I
personally consider the way Trinidad handles skinning one of the weak
points which should be considered to be thought over.
The reason for this simply was the experience seeing one developer
hammering his head against the table trying to learn how to skin it.
And it becomes worse with more complicated components.
I personally think the entire skinning aspect, while technologically
being really impressive with a CSS3 down to browser CSS support is a
huge problem for many to adapt the component library.
At least it should be simplified for certain components!
The UIX dependencies are another problem, but I personally consider
the complexity of component skinning an even bigger issue, which might
even be way harder to address!
