Apache MyFaces Orchestra Announced - integrates persistence with JSF

Discussions

News: Apache MyFaces Orchestra Announced - integrates persistence with JSF

  1. From the Apache MyFaces mailing list:
    We would like to announce the availability of Apache MyFaces Orchestra. Orchestra is "yet another try" to simplify the development of web applications using JPA or any other object relational mapper like plain Hibernate. In contrast to the other solutions we think ours is easier to use with a low learning curve. There are no new annotations required other than those you'll use for JPA, though, using Springs *Template classes to get access to the persistence context will do the trick too. With help of the Spring framework Apache MyFaces Orchestra introduce new scopes usable for your managed beans. For example you'll get a "conversation" scope where its lifetime is synchronized with the database session. This allows you to directly use the entities in your view, though, even if you use "data transfer objects" you'll find it convenient to gain from the persistence context session cache and keep things like automatic version checking without having to think about it. Further documentation can be found in the Apache MyFaces Orchestra "Core" Module. The next milestone is to work towards a 1.0 release, for now you can download snapshots as described on the download page. Thanks to everyone who made it possible to get this project alive. Have fun! Ciao, Mario

    Threaded Messages (27)

  2. From the Apache MyFaces mailing list:
    We would like to announce the availability of Apache MyFaces Orchestra.

    Orchestra is "yet another try" to simplify the development of web applications using JPA or any other object relational mapper like plain Hibernate.
    I want to add some additional info here. Orchestra is currently JSF only but its bindings towards JSF are very lightweight and have been refactored out into a separate package, nothing prevents anyone, to make bindings into other web frameworks. So if you are in need to have something along this in another framework, feel free to do it, the license does not prevent it and the framework as well. Also the annotation less approach was chosen so that others can build upon and hopefully will. Nothing prevents it to be integrated into other frameworks and it is encoraged to be done (It just is not done) Also currently there are adaptors towards Hibernate and JPA.
  3. Cool, but where's JSF 1.2?[ Go to top ]

    Shouldn't the MyFaces team just concentrate on their core 'business'? The JSF 1.2 final spec has been out for well over a year and their JSF implementation is still at 1.1. Reminds me a bit of the old Orion AS where J2EE 1.3 was also 'good enough' and 1.4 support would come 'someday'. Now, who's still using Orion these days?
  4. Re: Cool, but where's JSF 1.2?[ Go to top ]

    Shouldn't the MyFaces team just concentrate on their core 'business'? The JSF 1.2 final spec has been out for well over a year and their JSF implementation is still at 1.1.

    Reminds me a bit of the old Orion AS where J2EE 1.3 was also 'good enough' and 1.4 support would come 'someday'. Now, who's still using Orion these days?
    Ahem, to my knowledge myfaces 1.2 has passed the TCK a while ago, but still is not a final release due to other reasons (which to my knowledge from the mailinglists are non core codebase related). So myfaces 1.2 is there, and it is TCK compliant afaik, but it is not a final 1.2. As for coding this stuff. Mario the lead programmer of this stuff, did it as spinoff sideproject for stuff he had to work on anyway, so nothing man hourwise was removed from the myfaces 1.2 development (others are involved with that, Mario definitely was not)
  5. Re: Cool, but where's JSF 1.2?[ Go to top ]

    I don't care why..but they are missing a lot of important things. One of this is the 1.2 relese. Also if they are coming out now, they are still in late, very late. The 1.1 implementation is causing a lot of problems to developers, because many component libraries are working on MyFaces but not on RI 1.2 (that is IMHO much better then MyFaces). Other important points: -myfaces is still buggy respect to the sun implementation...fix it seriously and do not waste time on other things. Last day I discovered the f:converDateTime show a wrong date...it is MyFaces 1.1.5 (I am tired to see such bugs also in the newest release). -tomahawk is still buggy..fix that good component library and ensure that it works on every jsf implementation (some component doens't). -please add support Facelets. Tomahawk doesn't support natively Facelets. Some people wrote the taglib but it is out of date every time tomahawk add some features...facelets feature should be provided from the tomahawk team. But they don't undedstand maybe that 99% of us is using Facelets. -the same for Tobago and Trinidad (that absolutely doens't work on 1.2). And please, write decent documentation about them. My opinion is the MyFaces is too chaotic.
  6. Re: Cool, but where's JSF 1.2?[ Go to top ]

    I don't care why..but they are missing a lot of important things. One of this is the 1.2 relese. Also if they are coming out now, they are still in late, very late.

    The 1.1 implementation is causing a lot of problems to developers, because many component libraries are working on MyFaces but not on RI 1.2 (that is IMHO much better then MyFaces).

    Other important points:

    -myfaces is still buggy respect to the sun implementation...fix it seriously and do not waste time on other things. Last day I discovered the f:converDateTime show a wrong date...
    Can you give any specifics, did you post the issue already in the mailinglist. ConvertDateTime is a central converter and has been used for years, by many (including me) without too many problems, besides that it is a TCK covered converter to my knowledge.
    it is MyFaces 1.1.5 (I am tired to see such bugs also in the newest release).

    -tomahawk is still buggy..fix that good component library and ensure that it works on every jsf implementation (some component doens't).

    -please add support Facelets. Tomahawk doesn't support natively Facelets. Some people wrote the taglib but it is out of date every time tomahawk add some features...facelets feature should be provided from the tomahawk team. But they don't undedstand maybe that 99% of us is using Facelets.

    -the same for Tobago and Trinidad (that absolutely doens't work on 1.2). And please, write decent documentation about them.


    My opinion is the MyFaces is too chaotic.
    Ok point taken, you raise a lot of points here, many valid but to sum it up shortly: For the JSF 1.2 thing, you soon will be very pleased ;-) I cannot comment on fully trinidad, I have neither used it nor having had a look at the codebase, but they deliver a fully blown web application where you instantly can test the attributes. Besides that have a look at following site: http://myfaces.apache.org/trinidad/ there you have references into the Trinidad documentation and into the live demo Tomahawk core also has a similar documentation structure. Besides that there always is the myfaces wiki for additional information (there you can find a lot of tomahawk facelets coverage) As for facelets, they are a huge issue, to my knowledge Trinidad 1.0.1 (take it with a grain of salt) already has covered them. Tomahawk is somewhat of an issue, the codebase is partially very old and not all parts currently are covered by codegens. The facelets not being entirely covered in Tomahawk is unfortunately a somewhat partially unresolved issue. And also some bugs, we simply would love to have more people Most of the components are covered by the various sources by now, but new components yet are not covered, have in mind, this is an opensource project, and people donate and most people on tomahawk work on it in their sparetime often in the evenings and nights. So that this is often a little bit more chaotic than vendor driven development or some technology coverage can lack a little bit behind is unfortunately part of oss... All I can say is, OSS is a community thing, and if someone in the community finds something extremly lacking, give it a helping hand to improve the situation.
  7. Re: Cool, but where's JSF 1.2?[ Go to top ]

    Can you give any specifics, did you post the issue already in the mailinglist. ConvertDateTime is a central converter and has been used for years, by many (including me) without too many problems, besides that it is a TCK covered converter to my knowledge.
    Probably some timezone issue (it is deployed on italian server) that is not covered from the TCK. I found the same issue on 1.1.3 and it is documented in the mailing list... I found also big issues with back button (and state is saved on client!!). I could say etc etc.. I feel confortable with Sun Reference Implementation. It has very few bugs (none that I know at the moment) so I am not interested on help myfaces that gave me a lot of problems every time I tried. Ok this doens't mean I won't sumbmit issues etc.
  8. Re: Cool, but where's JSF 1.2?[ Go to top ]

    Can you give any specifics, did you post the issue already in the mailinglist. ConvertDateTime is a central converter and has been used for years, by many (including me) without too many problems, besides that it is a TCK covered converter to my knowledge.


    Probably some timezone issue (it is deployed on italian server) that is not covered from the TCK. I found the same issue on 1.1.3 and it is documented in the mailing list...
    Ok I will look into it. Not sure if this is entirely an issue of MyFaces or not just from 1.0, you might simply have to set explicitely the timezone. To my knowledge 1.0/1.1 does not have any timezone settings which come in from the browser. I will dig it up in the mailinglist to see why the bug is there and if it really is a bug and not just a shortcoming from the 1.1 implementation.
    I found also big issues with back button (and state is saved on client!!).
    Which ones?

    I could say etc etc..
    I feel confortable with Sun Reference Implementation. It has very few bugs (none that I know at the moment) so I am not interested on help myfaces that gave me a lot of problems every time I tried. Ok this doens't mean I won't sumbmit issues etc.
    Yes to my knowledge the Sun 1.2 RI is very good, they did an outstanding job.
  9. looks familiar[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?
  10. Re: looks familiar[ Go to top ]

    For me MyFaces Orchestra is cool because I do not want to use JBoss Seam. I prefer Sping than JBoss Seam.
  11. Re: looks familiar[ Go to top ]

    For me MyFaces Orchestra is cool because I do not want to use JBoss Seam. I prefer Sping than JBoss Seam.
    Ok, that's an argument, isn't it ;-) In our company we are using the Springframework indeed (for configuration and DI). Though we would never apply it just because we don't want any other. Bullsh*t. I'm not quite sure if I like the Springframework to manage my entities through spring scopes, though a Custom Scope is really a useful thing. But that's just because I did'nt think about it yet. A thing that annoys me is how lightly they invent the "conversation scope" (a database connection scope for beans). Which has been formerly and commonly known as a scope in Seam, that is something completely different. (some kind of a workflow scope). But no - you've got to call it a conversation. I do believe that you framework inventers are freaks. But moreover you're not very good in wording. Guys, you're speaking a language with many many words. Please: just try to find two different words (that can be understood by a simple-minded developer like me) for two completely different things.
  12. Re: looks familiar[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?
    TO my understanding the cool thing is less coupling. Somehow (how I do not know yet) beans with a db connection are injected into your data access objects, services or other beans. But how you do apply SQL / Object QL or other database statements I can only guess. Man, I should read their tutorials, yet another ORM tutorial :-)
  13. Re: looks familiar[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?


    TO my understanding the cool thing is less coupling. Somehow (how I do not know yet) beans with a db connection are injected into your data access objects, services or other beans.

    But how you do apply SQL / Object QL or other database statements I can only guess.

    Man, I should read their tutorials, yet another ORM tutorial :-)
    Well the thing which such systems is that you basically work on the db objects all the time if you want... ORM mappers usually are burdensome in web applications because you lose the objects most of the times over request boundaries or you keep one central session/entity manager open all the time which does the bookkeeping (which is a burden to ram and db connections). With orm controlling scope/conversation systems you basically keep the session/entity manager open as long as you need them and only apply the data on the db entity objects. Once you are done you flush those objects and are done with it. If you are in a context which does not have that (JDBC for instance or a rich client app framework) then there is no need for extended orm control. If you use orm systems which do not do any bookkeeping then any dialog/conversation system does it, but many orm mappers simply have some kind of object bookkeeping, and there you constantly run into exception like:"object is already loaded", "lazy binding session closed etc..." As for applying sql etc... this is done the usual way the orm mapper provides. Currently Hibernate and JPA are supported (one of the projects developed parallely to it was using Hibernate, the other one a plain JPA RI) and your entity manager is injected via springs mechanisms, so nothing changes there, the only thing which changes from standard spring is, that you can define spring beans with a custom scope conversation which you can programmatically control, the rest is pretty much standard spring (Transaction management, Connection management, DAO objects, or @Transactional annotations, all is provided straight from spring, even teh basic scope APIs orchestra hooks itself into). You can use the spring provided annotations, or leave them out it is up to you. You even can use the scopes/conversatios just for orm less scoping (just dont inject any PersistenceContext) The only limitations it currently has, is that it currently is bound to JSF because no one has done any other framework bindings yet (although it is very easily possible - but being a myfaces subproject JSF was logical as first step), and that there are no annotations or conversation controls outside of what spring provides or the Orchestra APIs provide. It is probably better that other more sophisticated conversation/scope controlling frameworks pick it up as scope/conversation provider/driver than Orchestra provides yet another conversation control mechanism outside of the boundaries of what spring can provide out of the box. There are loads of sophisticated high level dialog controlling frameworks and tools but most of them only do stateholding or just provided session like data structures. Anyway nothing of this should prevent anyone in using it, the framework works very well and is easy to use and feels very natural for any programmer familiar with Spring and has been applied to several projects already.
  14. Seam Replacement?[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?
    terracotta + spring + Apache MyFaces seems to be an answer to JBoss Seam. It's good to have alternative, I personally don't like Jboss at all and I don't want to use any of their product. (if you read posts from Bill and Gavin, and see how they attack their competitor, you should know why I hate them)
  15. Don't see how yet[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?


    terracotta + spring + Apache MyFaces seems to be an answer to JBoss Seam.
    I am curious to know what exactly *is* the answer? By telling what it does from what Seam can't would be *the* answer. Besides how this can be an answer if Seam also does spring + MyFaces just as easy? Btw having a feature matrix for comparison with Seam would be quite informative.

    It's good to have alternative, I personally don't like Jboss at all and I don't want to use any of their product.
    While having an alternative is certainly *nice*, just not 'liking' something is hardly an argument especially in a technical discussion.
    (if you read posts from Bill and Gavin, and see how they attack their competitor, you should know why I hate them)
    Ahem, from my perspective Seam gets attacked by Spring fanatics each time, but as you may guess it's pretty much subjective and not exactly on topic. Btw, is this product independent on JSF implementation? Anyway it would be interesting to watch the progress of the framework, who knows may be something nice will come out of it.
  16. Re: Don't see how yet[ Go to top ]

    I've been using Seam, and this sounds *really* familiar to that of Seam's managed-persistence context. Where's the "cool" factor?


    terracotta + spring + Apache MyFaces seems to be an answer to JBoss Seam.


    I am curious to know what exactly *is* the answer? By telling what it does from what Seam can't would be *the* answer. Besides how this can be an answer if Seam also does spring + MyFaces just as easy? Btw having a feature matrix for comparison with Seam would be quite informative. Well to go now into the obvious Seam comparisons, this stuff definitely is not something which should compete with seam, it has some similarities yes, but... Seam tries to be an all in one framework which tries to cover a lot more ground. For now orchestra is mostly just a custom scope for Spring which does cover the orm/scope handling. There also is a dynaform component, but that is somewhat out of the scope of orchestra itself. The idea of orchestra was to have a subproject of useful things which were developed over time which cannot be covered by the existing component libraries. The main module of it for now is the ORM/Scope stuff for spring, it for now is unclear where the project is going to head besides what we have here. There are numerous options, if others want to join, the project probably could need bindings into more sophisticated dialog frameworks and other webframeworks. Second, at the time of development there was no Spring Seam integration. And to my knowledge the spring seam integration for now provides just a proxy into the ejb3 Seam layer and bypasses most of Springs scoping infrastructure. A perfect way to combine both infrastructures. Orchestra hooks itself into it, hence it has strong ties into spring but very shallow ties into the webframework it connects itself into (hence it can be docked very easily onto other webframeworks) Just to say it again, orchestra does not really want to compete with Seam, and probably will never achieve the scope of what Seam tries to solve. There are many szenarios where you do not need a full EJB3 infrastructure, but you need custom scopes and a more advanced platform neutral orm controlling in combination, and this is where orchestra for now can kick in.
  17. Re: Don't see how yet[ Go to top ]

    While having an alternative is certainly *nice*, just not 'liking' something is hardly an argument especially in a technical discussion.
    Yep, it's not technical, it's all about *personal* as I said :)
    Seam gets attacked by Spring fanatics each time
    this is true, they are only spring USER, Not the guys from i21, unlike Gavin and Bill. I can put loads of links of their post if you want.
    I am curious to know what exactly *is* the answer
    I'm not trying have a war here, I just think the selling point of Seam is it programing model, stateful bean with extend persistence .... which can be done easily with Apache MyFace + terracotta with sping custom scope. Correct me if I'm wrong Cheers, Nathan
  18. Re: Don't see how yet[ Go to top ]

    I'm not trying have a war here, I just think the selling point of Seam is it programing model, stateful bean with extend persistence ....

    which can be done easily with Apache MyFace + terracotta with spring custom scope.
    First off, it's not just the features in Seam, but the depth with which they are integrated with each other which makes Seam great to work with. Some people like to pick and choose their own framework elements, and then spend time getting them to work with each other, tracking dependencies, and dodging caveats. Personally, I just want to fire up new app (takes about 1 minute with Seam-Gen), and get busy. By sticking with a select set of framework elements, Seam is able to thoroughly integrate with all of them. When you have a problem, everyone on the forums are using the same elements making troubleshooting much easier. With the soon to be released Red Hat developer studio bringing the same level of integration at the IDE level, I think Seam will be Orchestra approximates to the Seam persistence management pieces, but Seam is so much more than that. Seam not only provides dependency injection (a la Spring) but also dependency bijection so I can actually push beans out into the context, possibly for it to be injected somewhere else. There is also the JBpm page flow engine for making navigation more logical and intelligent, as well as the fact that the JBoss IDE tools include a nice visual page flow designer. It also has the work flow engine to provide work flow functionality that can span users and sessions. It also handles many of the issues that plague web developers, such as providing mechanisms for handling 'open in new tab/window' by isolating the context variables in a conversation. It also accommodates the back button for you in a sensible way. It also enhances conversation management by letting you provide custom IDs for conversations such as using the widgetId as the conversation Id. In the next release, if you try and start a new conversation with the same Id, Seam will automatically pick up the new conversation for you so your users won't be able to edit the same item twice, at least, not in two conversations. Seam also provides renderkits for PDF, so you can define a PDF document using JSF, complete with EL bindings into your same old backing and entity beans. It also provides a feature to let you write JSF based emails, again using the JSF EL language to access Seam beans. Both of these let you use facelets as a templating engine. It extends JSF in many useful ways that fit well with Seam model, links and buttons that perform a POST and redirect so you can have bookmarkable URLs, and can also perform actions on the backing bean, start conversations and/or pageflows. Automatically passing parameters across requests and letting the Faces Message survive beyond the redirect as well as letting you use parameters in backing bean actions are other ways it extends JSF. Seam also integrates tightly with Ajax4Jsf and RichFaces, again, some people want to pick their own ajax technology, me, I just want to use something with as little configuration, twiddling, or dependency hassles as possible. It's a great library and I am sure it will get better, but Seam can be used with any JSF library such as iceFaces. I suggest downloading Seam just to read through the reference manual, or looking at it online. Spring seams to have beat the stateless web app drum for so long, and now people are looking at Ajax and realizing that you need some state in there and are looking for projects like Orchestra and Spring Web Flow to provide some kind of state management. What I find interesting is that such add-ons for JSF would probably not be possible or numerous if not for the 'over engineered' nature of the JSF framework that so many complain about.
  19. Re: Don't see how yet[ Go to top ]

    First off, it's not just the features in Seam, but the depth with which they are integrated with each other which makes Seam great to work with.
    I agree that people are missing the point, the integration provided by JBoss certainly has merits.
    Spring seams to have beat the stateless web app drum for so long, and now people are looking at Ajax and realizing that you need some state in there and are looking for projects like Orchestra and Spring Web Flow to provide some kind of state management.
    Well put, there is not much you can do with a stateless web app that is really interesting (rich). I dislike Spring Web Flow because they should have stuck with JSF rather than inventing a better "Struts with DI". As for the comment about MyFaces, I think Orchestra is the type of thing MyFaces should be doing, why write another RI when the one put out by Sun is good enough. Honestly, the JSF RI and what it does is not very deep. We need component libraries and extended solutions that make JSF web applications work so I think this is exactly what MyFaces community should be doing rather than focusing on RI
  20. Re: Don't see how yet[ Go to top ]

    First off, it's not just the features in Seam, but the depth with which they are integrated with each other which makes Seam great to work with.


    I agree that people are missing the point, the integration provided by JBoss certainly has merits.

    Spring seams to have beat the stateless web app drum for so long, and now people are looking at Ajax and realizing that you need some state in there and are looking for projects like Orchestra and Spring Web Flow to provide some kind of state management.


    Well put, there is not much you can do with a stateless web app that is really interesting (rich). I dislike Spring Web Flow because they should have stuck with JSF rather than inventing a better "Struts with DI".
    Well Spring webflow is framework agnostic, if you need something along the lines of Spring webflow and JSF then Shale Dialog might be the better option. Anyway orchestra left out the annotations and other stuff, deliberatly because there are engines like Spring Webflow or Shale dialog which can provide better high level state control. We can only hope the other frameworks will pick it up.


    As for the comment about MyFaces, I think Orchestra is the type of thing MyFaces should be doing, why write another RI when the one put out by Sun is good enough. Honestly, the JSF RI and what it does is not very deep. We need component libraries and extended solutions that make JSF web applications work so I think this is exactly what MyFaces community should be doing rather than focusing on RI
    Actually dont forget, MyFaces back in those days was the only opensource implementation. The RI was opensourced only a while ago, and still MyFaces has a more liberal license for integration. (Not that the CDDL is very limiting though) MyFaces definitely gave sun a serious push about opensourcing their JSF implementation and to work on the quality.
  21. Re: Don't see how yet[ Go to top ]

    Actually dont forget, MyFaces back in those days was the only opensource implementation. The RI was opensourced only a while ago, and still MyFaces has a more liberal license for integration. (Not that the CDDL is very limiting though) MyFaces definitely gave sun a serious push about opensourcing their JSF implementation and to work on the quality.
    I don't think that at the time MyFaces RI was a bad thing. Its a sad story that an open group initiative was needed to get a company like Sun (and I don't mean to leave others like IBM off the hook) to put out quality code. It is probally the biggest difference from .Net/Microsoft world and Java that being commitment by companies to quality. My point is that MyFaces should drop even trying to do a 1.2 implementation and focus on Components (Tobago, Trinidad) and additions like Orchestra. MyFaces might also focus on extracting the framework that have for building components more easily from the RI and make that the project. What is Apache/MyFaces gonna do on Ajax front?
  22. Re: Don't see how yet[ Go to top ]

    Actually dont forget, MyFaces back in those days was the only opensource implementation. The RI was opensourced only a while ago, and still MyFaces has a more liberal license for integration.
    (Not that the CDDL is very limiting though)
    MyFaces definitely gave sun a serious push about opensourcing their JSF implementation and to work on the quality.


    I don't think that at the time MyFaces RI was a bad thing. Its a sad story that an open group initiative was needed to get a company like Sun (and I don't mean to leave others like IBM off the hook) to put out quality code. It is probally the biggest difference from .Net/Microsoft world and Java that being commitment by companies to quality.

    My point is that MyFaces should drop even trying to do a 1.2 implementation and focus on Components (Tobago, Trinidad) and additions like Orchestra. MyFaces might also focus on extracting the framework that have for building components more easily from the RI and make that the project. What is Apache/MyFaces gonna do on Ajax front?
    Actually if you are interested in the Ajax front, check out the latest developments in the components on all three component frameworks, also there is some stuff not in myfaces (for instance ajax based partial page rendering was added recently in Trinidad, it used to use iframes) but in Shale which is complementary. As for adding specific APIs regarding Ajax, MyFaces is bound by the specifications in this area, and while JSF 1.2 adds a few things, the real push towards Ajax will come in JSF 2.0 if you look at the roadmap.
  23. Orchestra[ Go to top ]

    Hi! Compared to Seam a feature matrix will be very sparsely populated. Apache MyFaces Orchestra just helps you keeping your database entities associated with the persistence context during a conversation which can be longer than a http request but shorter than the http session. This is the one and only noteworthy feature we share with Seam. The main difference here is, that we try to achieve this by simply provide a new scope. You just write managed beans as you used to. Thus, I think the main argument pro Orchestra is, that it will be easier to jump into development. You just have to learn how to configure your JSF backing bean in your spring configuration and a hand full of api calls. Overall, there is no new "paradigm". Orchestra is independent of the JSF implementation, if not, it would be a bug. It even should be possible to switch the web framework at all, as of now, we have very little connections to JSF. The addressed dynaForm JSF component; which you'll find in our core15 module; helps you developing highly dynamic forms. Its in beta stage and not yet documented, well, I use it in our company already. This component creates the JSF component used for data tables or forms at runtime. Compared to code-generation this might limit its use-case a little, though, this way allows you to have your forms automatically be adjusted to your entity. Here, I also process the hibernate-validation annotations and associate them to the corresponding JSF validator. Next thing we try to do here - and which brings this component ahead code-generation solutions - is, that the use should be able to choose itself which properties of an entity (or one of the embedded classes) to show. That allows you to customize you application in a new way. On the other hand, this dynaForm component will never make it needless to hand code forms ... but this wasn't and will never be the goal of this component. Ciao, Mario
  24. maybe it is better to Orchestra[ Go to top ]

    To Orchestra Guys. Well done! Please decouple the project from JSF. I'd like to try Orchestra with other frameworks (GWT and Struts for an instance). To Spring Guys. Maybe it is time to have such sub project as part of Spring? To Guys who points that JSF 1.2 is not ready yet. You do as smart as those who is blaming on Hibernate developers forum that Jboss5 is not ready yet. --Mark

  25. To Guys who points that JSF 1.2 is not ready yet.
    No one is saying that JSF 1.2 is not ready. Sun implementation is 1.2 since 2006, and we are using it (and personally I am really satisfied). MyFaces is not ready, thought they are coming out (I have beend hear this sinece may and now we are going into july... :|) Do not confuse JSF with MyFaces please ;)
  26. )
    Do not confuse JSF with MyFaces please ;)
    Of course I mean JSF 1.2 implementations. hope you are agree with the rest ;-) --Mark
  27. I am really amazed reading through the responses at peoples knee jerk reactions. 1. This is certainly an alternative to SEAM. To those who like JBOSS and SEAM continue on, to those looking for a 'Conversation' scope, this is a welcomed addition. 2. The term conversation actually comes from EJB, lets give credit to JBOSS for extending term to RI, for those who don't know what it means then well ... 3. For those who don't know why this is a big deal in JSF or in the DI world then you probally have not put together a real rich or AJAX application. To me a 'conversation' scope is a must for RIA. 4. To the Orchestra team kudo's for bring us this soluton. Question: I have actually put something like this (extended scopes) together a year ago. My only question is why put this on top of an ORM and make it an AOP type solution? I do agree that making it an extension to Spring ultimately takes away some of the charm for me. My feeling is that this should have been put on top of a cache implementation not an ORM solution. I will into it more before I pass judgement but I am glad others are thinking about solutions is this important space.
  28. I do agree that making it an extension to Spring ultimately takes away some of the charm for me. My feeling is that this should have been put on top of a cache implementation not an ORM solution.

    I will into it more before I pass judgement but I am glad others are thinking about solutions is this important space.
    Well the whole thing started about a year ago as a tag based solution which was framework neutral. (Sort of as an extended saveState tag) But then it was moved over to spring, spring was the logical choice since it was lacking a solution like that, but provided the entire infrastructure for extended scope handling and framework neutral orm handling. It is not built upon an orm solution, you can use the entire thing orm less, it just hooks itself into springs orm handling and you can turn that on optionally (currently only for hibernate and jpa) If you use it orm less, you just have extended scopes, with some goodies like optional callbacks for "scope being bound" "scope being unbound" in your beans.