Hi all, About JSF 2.0 adoption, I know there's a big hype in the JSF community about it. However, unlike1.1 and akin to 1.2, 2.0 is part of JEE and has some dependencies on some other specifications from it. Therefore, it's unlikely that simply dropping the jsf 2.0 jars will be enough to use 2.0, it might requires some additional jars as well. As a result, I think massive adoption of JSF 2.0 won't come before the massive adoption of JEE 6 that cannot happen until JEE 6 AS get released. I believe the latter is why it took so long for JSF 1.2 to be adopted. Then again, JEE 5 included MASSIVE changes so it's very possible that JEE 6 does suffer a delay as long before seeing AS in production version.
As for skinning, I agree with Scott. Trinidad's skinning enchine is very decent. However, I also agree that I see many developers bang their head when trying to skin something, sometimes myself even. Some of the main issues I suffer from are things like: <element class="tr_component"> <span class="DefaultFontColor">Text</span> </element> So when trying to set the color on the component, the more global selector takes preceedence which is annoying and force usage of tr|component .DefaultFontColor complex selector. Another problem I have that was even more important before -tr-inhibit time is the unknown alias inclusion. I raised that issue during incubation but my suggestion was discarded at a time. I could raise again that suggestion with a modification. I think we should provide three skins with Trinidad, not only basic and simple like now. Those skins would be: 1. empty: An empty skin with no selector at all (this skin wouldn't be necessary if no extends in the skin definition was meaning inherit nothing rather than simple) 2. coherence extends empty: A skin defining empty aliases and aliases inclusion, basically servign as a base of a skin using coherent styling across its components 3. simple extends coherence: Define the quite ugly green values in the alias and add some other styling information about layout and icons. So, when creating a new skin, developers could start out from scratch if they prefer and thus not suffer from unexpected side effects. Regards, ~ Simon On Mon, Oct 6, 2008 at 8:24 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > 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! >> >> >
