Ok, now I understand... I think it is "one" of the problems. Instead thinking about what it is > wrong, I'm trying to thing on which steps should we take to enhance > trinidad. > > If the objective is rewrite trinidad components using a theorical > javascript library, it is necessary to take these steps first: > > 1. Document current trinidad javascript api and identify what do we need to > implement, or in other words, which part of the code is api and which one is > implementation details. > > 2. Try to make easier generate custom components using trinidad. >
you are addressing the infrastructure "fault" to easier the next step... agreed. Thanks, Walter Mourão http://waltermourao.com.br http://arcadian.com.br http://oriens.com.br 2011/3/12 Leonardo Uribe <lu4...@gmail.com> > Hi Walter > > 2011/3/12 Walter Mourão <walter.mou...@gmail.com> > >> Hi Leonardo, >> >> I'm not sure I've got the idea... do you think the javascript >> documentation is THE big problem ? I really don't have an opinion because I >> didn't go deeper in Trinidad javascript code. >> > > I think it is "one" of the problems. Instead thinking about what it is > wrong, I'm trying to thing on which steps should we take to enhance > trinidad. > > If the objective is rewrite trinidad components using a theorical > javascript library, it is necessary to take these steps first: > > 1. Document current trinidad javascript api and identify what do we need to > implement, or in other words, which part of the code is api and which one is > implementation details. > > 2. Try to make easier generate custom components using trinidad. > > For the first step we can take the alternative I proposed before or even > better use the code proposed by Scott if it is donated to MyFaces. The > second step is being handled here: > > https://issues.apache.org/jira/browse/TRINIDAD-1409 > > >> >> In your opinion the best solution is just continue improving the current >> Trinidad client code ? As I stated before, my desire (so far) is the >> combination of Trinidad with a good javascript UI package, this way we could >> count with another community focused in the client side code. >> > > In my opinion we need to improve the current Trinidad client and java code > to open the possibility of new renderkits / components. I think the reason > why use a well known javascript library is it is more easier to users to > change to their needs. But maybe (note here I'm speculating) in some cases, > users does not need a full renderkit, instead they could need only to modify > one or two components, or maybe they just need to know where to change x or > y to make the component work as they expected. > > I think first we need to take action on the previous steps, and then we > should answer the checklist Werner (we can do it now, suggestions are > welcome). After that we'll have a clear course of action. > > regards, > > Leonardo Uribe > >