Re: Trinidad vs Tobago
Hi Helmut, it is an important goal to make it possible to run a Tobago 1.0.21 application with Tobago 1.1 with little or without effort. In particular cases, there a some changes to do, but the main idea is, that applications will run. To be compatible, you should not use code which is marked as deprecated, of course. For your project, you may start with 1.0 and switch to 1.1 if we have a stable release. Regards, Udo Helmut Swaczinna schrieb: Hi Udo, well, this sounds good. But what about the release plan for a stable 1.1.0 version? We're thinking about lauching a new project starting with 1.1.0 to have the benefits of the new layout manager. But our project schedule is very short, so we don't have the time to deal with new bugs etc. How about the compatibility between 1.0.x and 1.1.x. Is it possible to port a 1.0.x app to 1.1.x with little effort and vice versa? Regards Helmut Udo Schnurpfeil schrieb: Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. The tobago-1.0.x branch is stable and basis of the actual releases. The next release (1.0.21) will come up in the next days. This branch contains bugfixes and some (smaller) new features. You can see the changes of the next release here: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310273fixfor=12313470 The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: - make renderer more independent from the layout management. - more flexible - more type of layout managers - better testability (unit tests) - better support for browser-window resizing * New tree implementation * Better support for integrating 3rd party components * Client side coordinates of action event on server side (mouse event, click event) * simplify css and javascript files * support for many tabs * improved sheet performance * more support for other renderkits and many internal refactorings (plan) * Generating tag classes and components * Enhanced tobago lifecyle with buildView layoutView (registerResource) / encodeView (renderResponse) * UIPopup should be a subform * UITab should be a naming container (which tab contains a component with a Message) * Z-Index Provider * replace prototype with dojo * replace commons-logging with slf4j * Remove deprecated methods and classes * public and internal packages(public api and internal api) * remove some static classes * improved TobagoResponseWriter for javascript (JSON) * TabGroup should be an ActionSource * TabChangeEvent should be an ActionEvent * requiredMessage validatorMessage converterMessage for all EditableValueHolder in Tobago Regards Udo kanth99 schrieb: Hi all, Thanks for your replies. Groovie wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... I hope you are right, but i looks like (for me) that the development activity slowed down. 2008 was a great year an i was lucky using this wonderful component library. Could you give us a short insight of the current development ? I switched to Richfaces and found it also useful for me. What are the advantages or drawback of one lib comparing the other? Thanks Groovy of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. Trinidat looks a little bit old-fashioned to me, anyway there seems to be only a little support for AJAX. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth
Re: Trinidad vs Tobago
Hi Udo, well, this sounds good. But what about the release plan for a stable 1.1.0 version? We're thinking about lauching a new project starting with 1.1.0 to have the benefits of the new layout manager. But our project schedule is very short, so we don't have the time to deal with new bugs etc. How about the compatibility between 1.0.x and 1.1.x. Is it possible to port a 1.0.x app to 1.1.x with little effort and vice versa? Regards Helmut Udo Schnurpfeil schrieb: Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. The tobago-1.0.x branch is stable and basis of the actual releases. The next release (1.0.21) will come up in the next days. This branch contains bugfixes and some (smaller) new features. You can see the changes of the next release here: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310273fixfor=12313470 The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: - make renderer more independent from the layout management. - more flexible - more type of layout managers - better testability (unit tests) - better support for browser-window resizing * New tree implementation * Better support for integrating 3rd party components * Client side coordinates of action event on server side (mouse event, click event) * simplify css and javascript files * support for many tabs * improved sheet performance * more support for other renderkits and many internal refactorings (plan) * Generating tag classes and components * Enhanced tobago lifecyle with buildView layoutView (registerResource) / encodeView (renderResponse) * UIPopup should be a subform * UITab should be a naming container (which tab contains a component with a Message) * Z-Index Provider * replace prototype with dojo * replace commons-logging with slf4j * Remove deprecated methods and classes * public and internal packages(public api and internal api) * remove some static classes * improved TobagoResponseWriter for javascript (JSON) * TabGroup should be an ActionSource * TabChangeEvent should be an ActionEvent * requiredMessage validatorMessage converterMessage for all EditableValueHolder in Tobago Regards Udo kanth99 schrieb: Hi all, Thanks for your replies. Groovie wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... I hope you are right, but i looks like (for me) that the development activity slowed down. 2008 was a great year an i was lucky using this wonderful component library. Could you give us a short insight of the current development ? I switched to Richfaces and found it also useful for me. What are the advantages or drawback of one lib comparing the other? Thanks Groovy of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. Trinidat looks a little bit old-fashioned to me, anyway there seems to be only a little support for AJAX. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth
Re: Trinidad vs Tobago
Yeah, I'm full aware of the situation described below. The main problem in trinidad is that oracle uses him as foundation for ADF Rich Faces, and that's the main reason why trinidad core isn't going to change dramatically. More components should come together with the community. For example, developing an application sometimes you need to make some components that doesn't exist in trinidad component library (or any other framework generally), and here is (for example) the power of the community in sharing this components. Some of them will be rejected as useless other as very useful. I remember my days working on Borland Delphi, all the power of this tool was in tons and tons of community contributed components. Why, because it was easy to make them. Of course, today JSF developers are still making custom components, but they to not relay on trinidad framework. Another problem with suggestions is that when you need some component, usually you can't wait so long time, in meantime you find another solution, and after that there is no need for this component any more. -- But this is just my point of view. IE6 will be still around next 1-2 years, so unfortunately this will be and still is a big pain . Luka Surija +385 1 61 99 140 +385 98 434 061 l...@iytim.hr I.Y. tim d.o.o. Vrbik 3, HR-1 Zagreb www.iytim.hr i...@iytim.hr Andrew Robinson wrote: Yes I agree with you. The architecture needs more documentation, especially there are some really important API classes that have no JavaDoc at all. As for the maven-faces-plugin, I really dislike it. It does a nice job, but it is really hard to work with and modify (speaking from experience). There has been some discussion to move Trinidad to the new annotation builder plug-in, but I personally don't know the status of that and the opinion of the Trinidad contributors of changing the process. Yeah, writing that WIKI gave me typer's cramp, it was the last straw that pushed me to switch from QWERTY to the Dvorak keyboard layout, so I agree that it should be more simple. FYI, I think that there are maven archetypes out there that make it easier, but I am not 100% certain there is an appropriate one. As for more components, it is hard to write something that has no ideas. No one has put any effort into suggesting, working on or submitting new components to the Trinidad sandbox. So basically, if there is no demand for specific components, why spend your own personal time writing them and trying to guess what people want? Skinning is a lot of work and I started one skin, but I lost my motivation, but I think there is some that are working on one (search the dev@ archives). One problem I find with working with Trinidad is still supporting IE6 which makes life extremely miserable. The JS layer needs some major refactoring (like no global functions and using a trinidad namespace for all JS code for example) as well that makes any JS involved component be more work than it should be. Oracle still puts a lot of effort in Trinidad support and it still uses Trinidad as a base for the rich client framework (if you want to see the public demo, you can surf here: http://jdevadf.oracle.com/adf-richclient-demo/faces/index.jspx) so that is the primary reason that Trinidad's core framework is constantly worked on, but since Oracle has their own renderers for these components, there isn't the same focus on the Trinidad renderers as there is on the framework. Like all open source projects, there has to be a good user and contributor community for it to truly prosper. Should people work on new sandbox components and volunteer and start submitting patches for the skin framework, progress would be seen. As for how to contribute, it is as simple as creating JIRA tickets at http://issues.apache.org and submitting patches. If a patch seems to be growing old, then it is typical to ping the users@ or dev@ mailing list requesting someone to look into it. It helps if there is adequate comments. For any API changes, it is always best to discuss the change on the dev@ mailing list. Before I became a committer I just helped out on the mailing lists and submitted patches, it really is not too difficult to get involved if the desire is there. -Andrew On Fri, Jun 5, 2009 at 7:25 AM, Luka Surijaluka.sur...@iytim.hr wrote: Andrew, it's always the same reason. Trinidad is too complicated do extend without strong knowledge: 1. in it's architecture isn't well documented 2. in maven-faces-plugin I'm familiar with your wiki page ( http://wiki.apache.org/myfaces/Facelets_and_JSF_1.1_maven-faces-plugin_Getting_started ) but, as you can see it takes too much effort to make a simple hello world component and I think this is a main reason why there is almost no new components in last 2 years. I'm using trinidad since m1-incubating version and I'm tracking all the changes. In my opinion trinidad is potentialy the best jsf framework currently available,
Re: Trinidad vs Tobago
Yes I agree with you. The architecture needs more documentation, especially there are some really important API classes that have no JavaDoc at all. As for the maven-faces-plugin, I really dislike it. It does a nice job, but it is really hard to work with and modify (speaking from experience). There has been some discussion to move Trinidad to the new annotation builder plug-in, but I personally don't know the status of that and the opinion of the Trinidad contributors of changing the process. Yeah, writing that WIKI gave me typer's cramp, it was the last straw that pushed me to switch from QWERTY to the Dvorak keyboard layout, so I agree that it should be more simple. FYI, I think that there are maven archetypes out there that make it easier, but I am not 100% certain there is an appropriate one. As for more components, it is hard to write something that has no ideas. No one has put any effort into suggesting, working on or submitting new components to the Trinidad sandbox. So basically, if there is no demand for specific components, why spend your own personal time writing them and trying to guess what people want? Skinning is a lot of work and I started one skin, but I lost my motivation, but I think there is some that are working on one (search the dev@ archives). One problem I find with working with Trinidad is still supporting IE6 which makes life extremely miserable. The JS layer needs some major refactoring (like no global functions and using a trinidad namespace for all JS code for example) as well that makes any JS involved component be more work than it should be. Oracle still puts a lot of effort in Trinidad support and it still uses Trinidad as a base for the rich client framework (if you want to see the public demo, you can surf here: http://jdevadf.oracle.com/adf-richclient-demo/faces/index.jspx) so that is the primary reason that Trinidad's core framework is constantly worked on, but since Oracle has their own renderers for these components, there isn't the same focus on the Trinidad renderers as there is on the framework. Like all open source projects, there has to be a good user and contributor community for it to truly prosper. Should people work on new sandbox components and volunteer and start submitting patches for the skin framework, progress would be seen. As for how to contribute, it is as simple as creating JIRA tickets at http://issues.apache.org and submitting patches. If a patch seems to be growing old, then it is typical to ping the users@ or dev@ mailing list requesting someone to look into it. It helps if there is adequate comments. For any API changes, it is always best to discuss the change on the dev@ mailing list. Before I became a committer I just helped out on the mailing lists and submitted patches, it really is not too difficult to get involved if the desire is there. -Andrew On Fri, Jun 5, 2009 at 7:25 AM, Luka Surijaluka.sur...@iytim.hr wrote: Andrew, it's always the same reason. Trinidad is too complicated do extend without strong knowledge: 1. in it's architecture isn't well documented 2. in maven-faces-plugin I'm familiar with your wiki page ( http://wiki.apache.org/myfaces/Facelets_and_JSF_1.1_maven-faces-plugin_Getting_started ) but, as you can see it takes too much effort to make a simple hello world component and I think this is a main reason why there is almost no new components in last 2 years. I'm using trinidad since m1-incubating version and I'm tracking all the changes. In my opinion trinidad is potentialy the best jsf framework currently available, but it lacks some features to make it the best: 1. More components 2. easier component development 3. new AJAX under-layer to track component changes (to allow push technology one day). See ICEFaces as a example how to make a framework so popular with this technology. But in the background it lacks so many thing and nobody cares. I've tried ICEFaces, and for hello world application is ok, but for anything more complex, trinidad is 100x better and more developer friendly + has better browser compatibility. 4. wow skin to make him more attractive. I'm sure that many trinidad users (developers) are willing to contribute to the community starting from my self if they knew how to do it in some easier way. Best regards, Luka Surija +385 1 61 99 140 +385 98 434 061 l...@iytim.hr I.Y. tim d.o.o. Vrbik 3, HR-1 Zagreb www.iytim.hr i...@iytim.hr Andrew Robinson wrote: I would not jump to just saying that's totally wrong ... when there is truth to the observation. I cannot speak for Tobago, but there are areas of Trinidad that have not significantly changed in years. This may give the impression that there is not much ongoing development. What you find with Trinidad is that the server side framework is very well supported, as well as the components classes, but the Renderers, skins and JavaScript of Trinidad are very much neglected. This is
Re: Trinidad vs Tobago
While we're on this subject, I think it's clear that combining the component suites might increase the available resources for moving things forward.. I know this has been discussed in the past, but I don't think there was a clear consensus... --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 On Mon, Jun 8, 2009 at 5:35 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Yes I agree with you. The architecture needs more documentation, especially there are some really important API classes that have no JavaDoc at all. As for the maven-faces-plugin, I really dislike it. It does a nice job, but it is really hard to work with and modify (speaking from experience). There has been some discussion to move Trinidad to the new annotation builder plug-in, but I personally don't know the status of that and the opinion of the Trinidad contributors of changing the process. Yeah, writing that WIKI gave me typer's cramp, it was the last straw that pushed me to switch from QWERTY to the Dvorak keyboard layout, so I agree that it should be more simple. FYI, I think that there are maven archetypes out there that make it easier, but I am not 100% certain there is an appropriate one. As for more components, it is hard to write something that has no ideas. No one has put any effort into suggesting, working on or submitting new components to the Trinidad sandbox. So basically, if there is no demand for specific components, why spend your own personal time writing them and trying to guess what people want? Skinning is a lot of work and I started one skin, but I lost my motivation, but I think there is some that are working on one (search the dev@ archives). One problem I find with working with Trinidad is still supporting IE6 which makes life extremely miserable. The JS layer needs some major refactoring (like no global functions and using a trinidad namespace for all JS code for example) as well that makes any JS involved component be more work than it should be. Oracle still puts a lot of effort in Trinidad support and it still uses Trinidad as a base for the rich client framework (if you want to see the public demo, you can surf here: http://jdevadf.oracle.com/adf-richclient-demo/faces/index.jspx) so that is the primary reason that Trinidad's core framework is constantly worked on, but since Oracle has their own renderers for these components, there isn't the same focus on the Trinidad renderers as there is on the framework. Like all open source projects, there has to be a good user and contributor community for it to truly prosper. Should people work on new sandbox components and volunteer and start submitting patches for the skin framework, progress would be seen. As for how to contribute, it is as simple as creating JIRA tickets at http://issues.apache.org and submitting patches. If a patch seems to be growing old, then it is typical to ping the users@ or dev@ mailing list requesting someone to look into it. It helps if there is adequate comments. For any API changes, it is always best to discuss the change on the dev@ mailing list. Before I became a committer I just helped out on the mailing lists and submitted patches, it really is not too difficult to get involved if the desire is there. -Andrew On Fri, Jun 5, 2009 at 7:25 AM, Luka Surijaluka.sur...@iytim.hr wrote: Andrew, it's always the same reason. Trinidad is too complicated do extend without strong knowledge: 1. in it's architecture isn't well documented 2. in maven-faces-plugin I'm familiar with your wiki page ( http://wiki.apache.org/myfaces/Facelets_and_JSF_1.1_maven-faces-plugin_Getting_started ) but, as you can see it takes too much effort to make a simple hello world component and I think this is a main reason why there is almost no new components in last 2 years. I'm using trinidad since m1-incubating version and I'm tracking all the changes. In my opinion trinidad is potentialy the best jsf framework currently available, but it lacks some features to make it the best: 1. More components 2. easier component development 3. new AJAX under-layer to track component changes (to allow push technology one day). See ICEFaces as a example how to make a framework so popular with this technology. But in the background it lacks so many thing and nobody cares. I've tried ICEFaces, and for hello world application is ok, but for anything more complex, trinidad is 100x better and more developer friendly + has better browser compatibility. 4. wow skin to make him more attractive. I'm sure that many trinidad users (developers) are willing to contribute to the community starting from my self if they knew how to do it in some
Re: Trinidad vs Tobago
Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. The tobago-1.0.x branch is stable and basis of the actual releases. The next release (1.0.21) will come up in the next days. This branch contains bugfixes and some (smaller) new features. You can see the changes of the next release here: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310273fixfor=12313470 The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: - make renderer more independent from the layout management. - more flexible - more type of layout managers - better testability (unit tests) - better support for browser-window resizing * New tree implementation * Better support for integrating 3rd party components * Client side coordinates of action event on server side (mouse event, click event) * simplify css and javascript files * support for many tabs * improved sheet performance * more support for other renderkits and many internal refactorings (plan) * Generating tag classes and components * Enhanced tobago lifecyle with buildView layoutView (registerResource) / encodeView (renderResponse) * UIPopup should be a subform * UITab should be a naming container (which tab contains a component with a Message) * Z-Index Provider * replace prototype with dojo * replace commons-logging with slf4j * Remove deprecated methods and classes * public and internal packages(public api and internal api) * remove some static classes * improved TobagoResponseWriter for javascript (JSON) * TabGroup should be an ActionSource * TabChangeEvent should be an ActionEvent * requiredMessage validatorMessage converterMessage for all EditableValueHolder in Tobago Regards Udo kanth99 schrieb: Hi all, Thanks for your replies. Groovie wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... I hope you are right, but i looks like (for me) that the development activity slowed down. 2008 was a great year an i was lucky using this wonderful component library. Could you give us a short insight of the current development ? I switched to Richfaces and found it also useful for me. What are the advantages or drawback of one lib comparing the other? Thanks Groovy of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. Trinidat looks a little bit old-fashioned to me, anyway there seems to be only a little support for AJAX. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth
Re: Trinidad vs Tobago
Salut Udo, Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. looks like, . that i was wrong. Tobago is still alive, great. The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: (...) Another topic you may not thought before. Please reactivate the foreach! I had to code a database driven form with a couple of altering types of input-fields and selection boxes. The jsf-page was programmed as a dynamic formular engine. The taglib met almost all requirements i needed, with one exception: foreach !!! For this reason i hat to abuse the table tag, cause this was the only remaining container-element, that acts like a foreach. This solution had one drawback, the table size does not grow with its contents. So i estimated the size by couting the containing elements and patch the rows/size of the table, b. [stage direction to the audience] time to boo Groovie Voilá, that was the reason, why i needed foreach! Groovy Regards Udo Thanks for your good job. Does your company still uses Tobago ?
Re: Trinidad vs Tobago
Hi Christian, I know the issue with the forEach. There are many aspects to notice with the interation stuff. I've written a sample for tobago 1.0.x which works with the c:forEach from the JSTL. But this not works with Facelets and also not with JSP-Tag-Files (because scriptlets are not allowed). I think we will find a solution for Tobago 1.1, but I can't promise it in the moment. An other aproach might be using a binding to a UIPanel, an building the components with Java-Code. That is not nice and has some pitfalls, but may a solution for you. Hope that helps Udo Christian Groove schrieb: Salut Udo, Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. looks like, . that i was wrong. Tobago is still alive, great. The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: (...) Another topic you may not thought before. Please reactivate the foreach! I had to code a database driven form with a couple of altering types of input-fields and selection boxes. The jsf-page was programmed as a dynamic formular engine. The taglib met almost all requirements i needed, with one exception: foreach !!! For this reason i hat to abuse the table tag, cause this was the only remaining container-element, that acts like a foreach. This solution had one drawback, the table size does not grow with its contents. So i estimated the size by couting the containing elements and patch the rows/size of the table, b. [stage direction to the audience] time to boo Groovie Voilá, that was the reason, why i needed foreach! Groovy Regards Udo Thanks for your good job. Does your company still uses Tobago ?
Re: Trinidad vs Tobago
I forgot the link: http://svn.apache.org/repos/asf/myfaces/tobago/branches/tobago-1.0.x/example/demo/src/main/webapp/best-practice/for-each.jsp Udo Schnurpfeil schrieb: Hi Christian, I know the issue with the forEach. There are many aspects to notice with the interation stuff. I've written a sample for tobago 1.0.x which works with the c:forEach from the JSTL. But this not works with Facelets and also not with JSP-Tag-Files (because scriptlets are not allowed). I think we will find a solution for Tobago 1.1, but I can't promise it in the moment. An other aproach might be using a binding to a UIPanel, an building the components with Java-Code. That is not nice and has some pitfalls, but may a solution for you. Hope that helps Udo Christian Groove schrieb: Salut Udo, Hi all, let me explain the actual status of the Tobago development: We have branched the development into the tobago-1.0.x branch and the trunk which is the next major release. looks like, . that i was wrong. Tobago is still alive, great. The trunk (1.1.x) is an area of many refactorings and implementation of new features. But the status is still alpha. Here is a list of issues for the next major release: * Reimplementation of the layout management: (...) Another topic you may not thought before. Please reactivate the foreach! I had to code a database driven form with a couple of altering types of input-fields and selection boxes. The jsf-page was programmed as a dynamic formular engine. The taglib met almost all requirements i needed, with one exception: foreach !!! For this reason i hat to abuse the table tag, cause this was the only remaining container-element, that acts like a foreach. This solution had one drawback, the table size does not grow with its contents. So i estimated the size by couting the containing elements and patch the rows/size of the table, b. [stage direction to the audience] time to boo Groovie Voilá, that was the reason, why i needed foreach! Groovy Regards Udo Thanks for your good job. Does your company still uses Tobago ?
Re: Trinidad vs Tobago
Andrew, it's always the same reason. Trinidad is too complicated do extend without strong knowledge: 1. in it's architecture isn't well documented 2. in maven-faces-plugin I'm familiar with your wiki page ( http://wiki.apache.org/myfaces/Facelets_and_JSF_1.1_maven-faces-plugin_Getting_started ) but, as you can see it takes too much effort to make a simple hello world component and I think this is a main reason why there is almost no new components in last 2 years. I'm using trinidad since m1-incubating version and I'm tracking all the changes. In my opinion trinidad is potentialy the best jsf framework currently available, but it lacks some features to make it the best: 1. More components 2. easier component development 3. new AJAX under-layer to track component changes (to allow push technology one day). See ICEFaces as a example how to make a framework so popular with this technology. But in the background it lacks so many thing and nobody cares. I've tried ICEFaces, and for hello world application is ok, but for anything more complex, trinidad is 100x better and more developer friendly + has better browser compatibility. 4. wow skin to make him more attractive. I'm sure that many trinidad users (developers) are willing to contribute to the community starting from my self if they knew how to do it in some easier way. Best regards, Luka Surija +385 1 61 99 140 +385 98 434 061 l...@iytim.hr I.Y. tim d.o.o. Vrbik 3, HR-1 Zagreb www.iytim.hr i...@iytim.hr Andrew Robinson wrote: I would not jump to just saying that's totally wrong ... when there is truth to the observation. I cannot speak for Tobago, but there are areas of Trinidad that have not significantly changed in years. This may give the impression that there is not much ongoing development. What you find with Trinidad is that the server side framework is very well supported, as well as the components classes, but the Renderers, skins and JavaScript of Trinidad are very much neglected. This is probably a result of many that extend Trinidad but do not necessarily contribute those extensions back. There is a Trinidad Sandbox, but unlike Tomahawk, there is no activity in it for the most part. I am not sure why this is and what we can do to motivate our users to provide new components and enhancements to existing components. So as a result, you will probably find that Trinidad is very solid, the server side keeps up to date with other libraries and with some new JSF technologies and there is a great community of support at the framework level. Just what is lacking is active support of the component offerings and the look and feel of Trinidad. As Apache relies on its users quite a bit, new patches, and new components are welcome, especially for the sandbox as it is a great testing ground for new ideas without having to perform all the architectural discussions up front. Then components can be brought into the core as they gain popularity and their architecture can be standardized if not already. -Andrew On Thu, Jun 4, 2009 at 9:00 AM, Matthias Wessendorf mat...@apache.org wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad vs Tobago
Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth
Re: Trinidad vs Tobago
On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad vs Tobago
On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... I hope you are right, but i looks like (for me) that the development activity slowed down. 2008 was a great year an i was lucky using this wonderful component library. Could you give us a short insight of the current development ? I switched to Richfaces and found it also useful for me. What are the advantages or drawback of one lib comparing the other? Thanks Groovy of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. Trinidat looks a little bit old-fashioned to me, anyway there seems to be only a little support for AJAX. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth
Re: Trinidad vs Tobago
I would not jump to just saying that's totally wrong ... when there is truth to the observation. I cannot speak for Tobago, but there are areas of Trinidad that have not significantly changed in years. This may give the impression that there is not much ongoing development. What you find with Trinidad is that the server side framework is very well supported, as well as the components classes, but the Renderers, skins and JavaScript of Trinidad are very much neglected. This is probably a result of many that extend Trinidad but do not necessarily contribute those extensions back. There is a Trinidad Sandbox, but unlike Tomahawk, there is no activity in it for the most part. I am not sure why this is and what we can do to motivate our users to provide new components and enhancements to existing components. So as a result, you will probably find that Trinidad is very solid, the server side keeps up to date with other libraries and with some new JSF technologies and there is a great community of support at the framework level. Just what is lacking is active support of the component offerings and the look and feel of Trinidad. As Apache relies on its users quite a bit, new patches, and new components are welcome, especially for the sandbox as it is a great testing ground for new ideas without having to perform all the architectural discussions up front. Then components can be brought into the core as they gain popularity and their architecture can be standardized if not already. -Andrew On Thu, Jun 4, 2009 at 9:00 AM, Matthias Wessendorf mat...@apache.org wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad vs Tobago
Hi all, Thanks for your replies. Groovie wrote: On Thu, Jun 4, 2009 at 2:21 AM, Christian Groove groo...@groovesytems.de wrote: Salut Hi All, We are developing a web application with myfaces. That's fine, JSF is the cool think. I worked with Tobago, that comes with a great layout manager and some cool widgets. It is not my intention to overwhelm that nice project but it seems to be dead. The development that's totally wrong ... I hope you are right, but i looks like (for me) that the development activity slowed down. 2008 was a great year an i was lucky using this wonderful component library. Could you give us a short insight of the current development ? I switched to Richfaces and found it also useful for me. What are the advantages or drawback of one lib comparing the other? Thanks Groovy of new widgets seems not to proceed so you may better look to other Taglibs like Richfaces, Icefaces. Groovy This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. Trinidat looks a little bit old-fashioned to me, anyway there seems to be only a little support for AJAX. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth -- View this message in context: http://www.nabble.com/Trinidad-vs-Tobago-tp23851748p23873832.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Trinidad vs Tobago
Hi All, We are developing a web application with myfaces. This application needs proper navigation and UI .I have observed Trinidad has good navigation practices and other utilities.Tobago has some good layouts but not good navigation practices.both these technologies have featurs like PPR. could some one plaese advice us which is the better technology and the distinct features of these technologies. Thanks, Srikanth -- View this message in context: http://www.nabble.com/Trinidad-vs-Tobago-tp23851748p23851748.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
