Re: MyFaces Fusion Name Poll App
Btw, this poll will not be anonymous, so that everyone can be sure that I don't manipulate the data. A (to be create) page will allow you to have a look at the vote of each voter. If you don't mind Hi! Using Apache MyFaces Fusion I've created a new example app: Ballot A tool to help make what I call dynamic votes. BTW: Even if there would have such a tool already there, I wanted to create another example for fusion. It is not meant to replace the voting on the ML, its just to distill those names worth to vote for. The dynamic part means, you can change your mind as long as the poll is open. You'll always be able to see the current state about each name. After registering you'll receive an url which allows you to cast a vote ... and change it again. Afterwards I'll take the top (say 5) names and we make a normal vote on the ML on them. No to the poll rules. I plan that you will be able to make 5 decisions per name, they are: -2 -1 0 1 2 What do you think, is this suitable? Ciao, Mario
Re: MyFaces Fusion Name Poll App
Another question is, if I should allow you to vote for each name, or if I should force you to cast your vote for e.g. 5 names only. Then changing the available vote selections should be 0 1 2 3 4 5, no? Hi! Using Apache MyFaces Fusion I've created a new example app: Ballot A tool to help make what I call dynamic votes. BTW: Even if there would have such a tool already there, I wanted to create another example for fusion. It is not meant to replace the voting on the ML, its just to distill those names worth to vote for. The dynamic part means, you can change your mind as long as the poll is open. You'll always be able to see the current state about each name. After registering you'll receive an url which allows you to cast a vote ... and change it again. Afterwards I'll take the top (say 5) names and we make a normal vote on the ML on them. No to the poll rules. I plan that you will be able to make 5 decisions per name, they are: -2 -1 0 1 2 What do you think, is this suitable? Ciao, Mario
Re: MyFaces Fusion Name Poll App
Top 5 On 3/3/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Another question is, if I should allow you to vote for each name, or if I should force you to cast your vote for e.g. 5 names only. Then changing the available vote selections should be 0 1 2 3 4 5, no? Hi! Using Apache MyFaces Fusion I've created a new example app: Ballot A tool to help make what I call dynamic votes. BTW: Even if there would have such a tool already there, I wanted to create another example for fusion. It is not meant to replace the voting on the ML, its just to distill those names worth to vote for. The dynamic part means, you can change your mind as long as the poll is open. You'll always be able to see the current state about each name. After registering you'll receive an url which allows you to cast a vote ... and change it again. Afterwards I'll take the top (say 5) names and we make a normal vote on the ML on them. No to the poll rules. I plan that you will be able to make 5 decisions per name, they are: -2 -1 0 1 2 What do you think, is this suitable? Ciao, Mario
Re: MyFaces Fusion Naming
Arash Rajaeeyan schrieb: and may be thats because shale has chosen a different approach? No... Actually I think the fusion conversation system is one level lower than shale dialog. While shale dialog basically follows the approach - configuration of dialog scopes, have something which can keep objects in ram during the dialog. the fusion conversation system is along the lines of: providing a programmatic accessible scope mechanism based on spring 2.0s basic scope control which also is able to handle orm entity manager control, no dialog configuration whatsoever (except for a spring bean entry). Nothing speaks against accessing this programmatic control from a configuration based dialog system, and only a few things currently prevent it from being accessible from other webframeworks outside of the jsf scope. But as Mario said, who knows what the future will bring.
Re: MyFaces Fusion Naming
On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: and may be thats because shale has chosen a different approach? No... Actually I think the fusion conversation system is one level lower than shale dialog. While shale dialog basically follows the approach - configuration of dialog scopes, have something which can keep objects in ram during the dialog. the fusion conversation system is along the lines of: providing a programmatic accessible scope mechanism based on spring 2.0s basic scope control which also is able to handle orm entity manager control, no dialog configuration whatsoever (except for a spring bean entry). Nothing speaks against accessing this programmatic control from a configuration based dialog system, and only a few things currently prevent it from being accessible from other webframeworks outside of the jsf scope. But as Mario said, who knows what the future will bring. One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? It looks like the core value add you wanted (managing the persistence tier resources at a per-conversation level instead of per-request) could have been done with SWF just as easily as writing your own conversation scope stuff. Craig
Re: MyFaces Fusion Naming
Hi Craig! One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? Don't know much about SWF, but we had a meeting with Jürgen Höller from interface21 where he helped designing the integration of the conversation scope with Spring including the persistence stuff. If SWF would have been possible to do this he would have said it. Also Fusion do depend on Spring 2, but not that hard ... for sure, it uses its possibility to create custom scopes and makes use of their persistence framework, though, its still modular enough that - if JSF will ever allow custom scopes - it can be plugged in there too. What might be possible is, that SWF make use of this new scope too - Fusion is also designed in a way that you can replace the web framework (in the important area). Maybe (I hope for the future) shale-dialog can make use of this scope too, and can provide a solution for the persistence that way. Ciao, Mario
Re: MyFaces Fusion Naming
Well... don't lets discuss that much about why another thing... Perhaps all these existing techniques can get their profit from the other one and can also give valuable feedback to web beans / jsr 299. I am happy that *Fusion* (or Kleber) has no dependency to WebFlow. I would prefer a closer connection to the Shale (Basic) Dialog. However... it's good to have the choice... Take a look at ORM or web frameworks... there are more than one, doing 99% same like the other... also the advent of JSF didn't stop that (like GWT for instance). Thx, Matthias On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig! One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? Don't know much about SWF, but we had a meeting with Jürgen Höller from interface21 where he helped designing the integration of the conversation scope with Spring including the persistence stuff. If SWF would have been possible to do this he would have said it. Also Fusion do depend on Spring 2, but not that hard ... for sure, it uses its possibility to create custom scopes and makes use of their persistence framework, though, its still modular enough that - if JSF will ever allow custom scopes - it can be plugged in there too. What might be possible is, that SWF make use of this new scope too - Fusion is also designed in a way that you can replace the web framework (in the important area). Maybe (I hope for the future) shale-dialog can make use of this scope too, and can provide a solution for the persistence that way. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
Hi Craig! That's where I don't understand Fusion enough to comment ... it originally appeared to me that the key value add was allocating the entity manager on the way in (when you created the conversation), and cleaning up afterwards when the conversation ended. Yes, this is one of the things we do, the other thing is, that we have to ensure for each call into the conversation scoped bean that this entity manager has been set to the thread so that the following classes will see this entity manager. This is where the Spring aop stuff provides REALLY nice things. That way, its possible to work with multiple conversations within one request; not that you can exchange the beans load by each other. You say, this should be solved at the servlet spec. And I think with our solution we are really close to it. The basic conversation scope works as if it is provided by the servlet spec. You have an additional scope and finding the scope context (multi window awareness) works through an url parameter which will be added by an servlet response wrapper (just like the session id without cookies). Thats why we are not bound to JSF in this area, there is simply no JSF code to achieve this. All I need is access to e.g the request map and session map, that has been refactored into a framework adapter, and if I would like to spend a servlet filter I can avoid even this. Ciao, Mario
Re: MyFaces Fusion Naming
Matthias Wessendorf schrieb: Well... don't lets discuss that much about why another thing... Perhaps all these existing techniques can get their profit from the other one and can also give valuable feedback to web beans / jsr 299. I am happy that *Fusion* (or Kleber) has no dependency to WebFlow. I would prefer a closer connection to the Shale (Basic) Dialog. Actually I personally think this is one area which is very important, Shale as excellent configuration patterns which are currently missing in fusion and a closer tie could benefit both frameworks I guess. Fusion started out from the idea of being able to have something conversational without having to have an entire configuration system, but there are many usecases where a conversation system can solve a lot of issues. So I personally now think, that having both and also having persistence control in it is probably the best way to go. No configuration for the easy usecases (which are the usual 50-70% and having something with more control on the configuration side for the more complicated ones. Funny that Seam started off as well configuration less, and now has moved into a we support both approach. However... it's good to have the choice... Take a look at ORM or web frameworks... there are more than one, doing 99% same like the other... also the advent of JSF didn't stop that (like GWT for instance). Actually there are not too many choices of such systems currently You only have seam and fusion/kleber which can do full persistencecontext control. I personally think, Seam is a work of pure genious, it is seldom that a first approach does most of the things right. But Seam itself, has too string tie ins into ejb3 and into jsf (I love ejb3 and I am not an enemy of JSF obviously, but I still see it as a problem) probably and makes some automatic assumptions which are perfectly ok for a framework which tries to ease things, but often you do not want to lose this control entirely. For instance one area of this we make the assumptions for you in Seam is the passing from the master to the detail which happens automatically. I once did a testprogram in Seam and thought afterwards to myself, what has happened here, I want to know... While it was good for the end user who does not want to think about it, something in there broke to my knowledge simply the way the tomahawk handles the tables, so tomahawk was incompatible to seams handling of master detail relationships. I am not going into detail here, because I neither remember the exact automatisms nor the exact details why the tomahawk table does not work. One of the problems I have faced the last week, was to find a way to handle the master detail relationships the way I wanted to have them, in a transparent way, which does not take away control. I had two ways I either could preinitialize the detail conversation in the master and load the detail or I could use the updateActionListener like I would anyway, I opted for a simple updateActionListener. Fusion was low level enough to leave me the control and did not take assumptions on how to handle things from me. I personally would love to see JSR299 go that way, not too make to many assumptions but keep it basic so that others can build upon it. This is too important to push a lot into it, that is probably one of the reasons why the servlets have served us so well for a long time, they kept things basic. And Craig, I agree, scoping should belong at the lowest level possible, but for now I am happy that there are solutions which ease the burden of taking away the endless request, merge, lazy loading, object keeping problems which have plagued us 10 years too long. Orm mappers are a joy to use, if you do not have to fight against them due to endless lazy loading, merge problems.
Re: MyFaces Fusion Documentation
Mario Ivankovits schrieb: Hi! I've started the documentation by creating two xdoc files in myfaces/fusion/core/src/site, now when I run mvn site from within myfaces/fusion it creates a site, but only a handful of pages in core/target/site and they do not use our stylesheet. Now: *) Shall I put the documentation into the module directory, or is it fine if I put them directly into fusion? For me its sufficient to have only one place for the documentation for the core and core15 modules. *) Anyway, what can be wrong with the site generation in fusion/core ? *) At last maven fail with directly into fusion would be fine by me, fusion is not so big that it needs a split already in the docs.
RE: MyFaces Fusion Naming
Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: Thomas Spiegl [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 6:28 PM To: MyFaces Development Subject: Re: MyFaces Fusion Naming another one ... Apache MyFaces Edge On 2/28/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Glad you liked it. Yeah I figured it would be pretty common name, but at least not as bad as Spyder! (taken by both SP ETF fund and major winter sports gear company) Anyway it's a cool name, but probably too common Mario Ivankovits wrote: Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
Hi ! Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... We developed it under the MyFaces umbrella during the last months, we started with a tag base way until we reached the spring based solution we have now. So, thats why it's still here. We will see what the future brings. Ciao, Mario
Re: MyFaces Fusion Naming
Might be significant that two people have asked this question so far :-) On 3/1/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi ! Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... We developed it under the MyFaces umbrella during the last months, we started with a tag base way until we reached the spring based solution we have now. So, thats why it's still here. We will see what the future brings. Ciao, Mario
Re: MyFaces Fusion Naming
and may be thats because shale has chosen a different approach? On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi ! Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... We developed it under the MyFaces umbrella during the last months, we started with a tag base way until we reached the spring based solution we have now. So, thats why it's still here. We will see what the future brings. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
Arash Rajaeeyan schrieb: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? Btw. speaking of JSR 299, and conversations, isnt jsr299 just a glue specification of marrying ejb3 and jsf so that you can use ejb3 beans as managed beans? Regarding conversations and dialogs: This stuff really belongs into the servlet space just like session and request, which technologies then are built on top of such scoping is an entire issue. Lets face it 90% of all problems most people have in webapps stem from the fact that you cannot keep objects for a longer time without going through the problems a session scope causes for garbage collection and due to the fact that if you do not work on a pure jdbc base but on an orm base you either have to keep an erm open for your entire session with all related problems or you have to open it on request or even works on business case and then run into the usual merge problems most orm layers have (which is not solvable in a satisfying way anyway) The current already big number of various dialog systems which also keep something conversational open for object storage stem from the fact that this is a huge problem or has become a bigger one now that webapps seem to have moved towards orm layers where this problem becomes more problematic. Tackeling it on JEE level has been long overdue in my opinion especially because most of the usage and core patterns basically are tested by now. Craig since you are reading this, any idea if the servlet specs will be opened to scopes/conversations in the next specifications? Werner
Re: MyFaces Fusion
On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? Btw. speaking of JSR 299, and conversations, isnt jsr299 just a glue specification of marrying ejb3 and jsf so that you can use ejb3 beans as managed beans? JSR299 means whatever the expert group decides to propose to the JCP executive committee for approval. The kinds of things you describe above are definitely within the initial proposal document[1], but I would not place any bets that JSR-299 will limit itself to just what you mentioned. Regarding conversations and dialogs: This stuff really belongs into the servlet space just like session and request, which technologies then are built on top of such scoping is an entire issue. Agreed in general ... the devil is in the details. Consider the RESTafarian attitude that scopes of any kind (other than request scope) are evil. And, consider the fact that, although javax.servlet was one of the earliest extension proposals for the Java language, there have not been any mainstream-adopted solutions on different APIs to adapt HTTP requests to Java business logic (unless, I suppose, you count SOAP mappings via things like JAX-RPC and JAX-WS ... but those still count IMHO as built on *top* of the servlet APi instead of replacing it). Maybe there is some virtue in a simple baseline standard that everyone can adopt? Lets face it 90% of all problems most people have in webapps stem from the fact that you cannot keep objects for a longer time without going through the problems a session scope causes for garbage collection and due to the fact that if you do not work on a pure jdbc base but on an orm base you either have to keep an erm open for your entire session with all related problems or you have to open it on request or even works on business case and then run into the usual merge problems most orm layers have (which is not solvable in a satisfying way anyway) The current already big number of various dialog systems which also keep something conversational open for object storage stem from the fact that this is a huge problem or has become a bigger one now that webapps seem to have moved towards orm layers where this problem becomes more problematic. Tackeling it on JEE level has been long overdue in my opinion especially because most of the usage and core patterns basically are tested by now. Craig since you are reading this, any idea if the servlet specs will be opened to scopes/conversations in the next specifications? It turns out that I've been an internal proponent of dealing with these kinds of issues at the servlet spec level, as my colleagues in the platform group are aware of :-). One of the critical challenges, unfortunately, is econimics -- funding any spec all the way through the JCP process is likely to be a six-figure ($) investment, and the challenge is to optimize our (Sun's) investments. My personal interest in this problem space is actually at a level *below* the servlet API ... hopefully, the recently filed RESTful API JSR can deal with those sorts of things. Things like conversation scope (and even session scope) should be extensions on top of such a basic API, not fundamental features of it. Serv;ets have served us honorably for almost 10 years (only a little less than the lifetime of Java itself) ... but it's time to move forwards. Werner Craig
Re: MyFaces Fusion
I think the best way is to extend the bean scopes and add some other scope(s) for conversation or dialogs. I think in first proposal they said they want to take best practices of Seam, Shale, ADF, and other JSF based frameworks and find best practices for web development, and put them in web beans (JSR 299) it can be addressed in low level Servlet API but it can also be addressed in higher levels like JSF frameworks. On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? Btw. speaking of JSR 299, and conversations, isnt jsr299 just a glue specification of marrying ejb3 and jsf so that you can use ejb3 beans as managed beans? Regarding conversations and dialogs: This stuff really belongs into the servlet space just like session and request, which technologies then are built on top of such scoping is an entire issue. Lets face it 90% of all problems most people have in webapps stem from the fact that you cannot keep objects for a longer time without going through the problems a session scope causes for garbage collection and due to the fact that if you do not work on a pure jdbc base but on an orm base you either have to keep an erm open for your entire session with all related problems or you have to open it on request or even works on business case and then run into the usual merge problems most orm layers have (which is not solvable in a satisfying way anyway) The current already big number of various dialog systems which also keep something conversational open for object storage stem from the fact that this is a huge problem or has become a bigger one now that webapps seem to have moved towards orm layers where this problem becomes more problematic. Tackeling it on JEE level has been long overdue in my opinion especially because most of the usage and core patterns basically are tested by now. Craig since you are reading this, any idea if the servlet specs will be opened to scopes/conversations in the next specifications? Werner -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
I wonder how Kleber sounds for English native speakers? regards, Martin On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 for Apache MyFaces Kleber On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
same like glue sounds to me ... On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I wonder how Kleber sounds for English native speakers? regards, Martin On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 for Apache MyFaces Kleber On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
Hey, I wonder how Kleber sounds for English native speakers? I bet it sounds horrible . I hope so :-) Ciao, Mario
Re: MyFaces Fusion Naming
Well, at times a word means something different in another language, or sounds like a different word? regards, Martin On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: same like glue sounds to me ... On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I wonder how Kleber sounds for English native speakers? regards, Martin On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 for Apache MyFaces Kleber On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
It probably sounds like Clever. It looks like Keebler (a cookie/cracker manufacturer). On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hey, I wonder how Kleber sounds for English native speakers? I bet it sounds horrible . I hope so :-) Ciao, Mario
Re: MyFaces Fusion Naming
Mike Kienenberger schrieb: It probably sounds like Clever. Hmmm I start to like it :-)
Re: MyFaces Fusion Naming
Ok, then I like it, and it gets my vote (on the other thread). regards, Martin On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike Kienenberger schrieb: It probably sounds like Clever. Hmmm I start to like it :-) -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
Manfred Geiler wrote: Apache MyFaces Orchestra? --Manfred I like the sound of this for a product. I agree though, that something along the lines of glue would be very intuitive for this particular subproject. btw, Kleber will draw blank stares from us english native-speakers. :D
RE: MyFaces Fusion Naming
I would pronounce Kleber as klee-ber with a long E sound like cleaver (a large knife or an instrument for cutting things apart, which might be ironic given the word's meaning in German). The word Kleber has no obvious meaning in English. Even after reading the description on the Wiki page, I still have no idea what this stuff is supposed to do or how it is to be used. If it has primarily to do with something called conversations (whatever that means), maybe use a name like conversation or a synonym in some language would be better? Richard J. Barbalace Cambridge, MA, USA -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 28, 2007 9:21 AM To: MyFaces Development Subject: Re: MyFaces Fusion Naming It probably sounds like Clever. It looks like Keebler (a cookie/cracker manufacturer). On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hey, I wonder how Kleber sounds for English native speakers? I bet it sounds horrible . I hope so :-) Ciao, Mario The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Re: MyFaces Fusion Naming
OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith
Re: MyFaces Fusion Naming
2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
I like em :D Thomas Spiegl wrote: 2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith
RE: Re: MyFaces Fusion Naming
I would avoid any nouns associated with 'heavy', I think it's contradictory to what Fusion is attempting to do. Stick to: http://thesaurus.reference.com/browse/fusion 2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
In that case, how about: Apache Myfaces Spider ...as in Spider Webs... obviously, can't use web itself :P [EMAIL PROTECTED] wrote: I would avoid any nouns associated with 'heavy', I think it's contradictory to what Fusion is attempting to do. Stick to: http://thesaurus.reference.com/browse/fusion 2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario
Re: MyFaces Fusion Naming
Glad you liked it. Yeah I figured it would be pretty common name, but at least not as bad as Spyder! (taken by both SP ETF fund and major winter sports gear company) Anyway it's a cool name, but probably too common Mario Ivankovits wrote: Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario
Re: MyFaces Fusion Naming
another one ... Apache MyFaces Edge On 2/28/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Glad you liked it. Yeah I figured it would be pretty common name, but at least not as bad as Spyder! (taken by both SP ETF fund and major winter sports gear company) Anyway it's a cool name, but probably too common Mario Ivankovits wrote: Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion
Sorry to jump in here again, I have been playing guinea pig the last week for marios work. All I can say is this thing now is highly usable by now. You can put a view controller under conversation scope (not a shale one yet, you will lose the callbacks) and simply work on the stuff now like you would do in a rich client environment with an EntityManage, Hibernate Session open for the entire conversation. once you hit a point when you want to terminate, you can have the view controller/conversation invalidate itself or restart itself. Also binding component bindings onto such a conversation is taken care of, you can push them into a separate bean which you weave in by a scope of request and aop:scoped-proxy, then you basically get a fresh view onto your backend component bindings at every request. To sum it up, I just almost finished a first full master detail crud ( I have done several details forms before) The master form has about 30 lines of core code, excluding the setters and getters already dealting with dao calling, handling the query part etc... and adding a detail was a matter of one hour of figuring out which patterns work best and a few minutes of implementation handling new update and delete. The objects you work with always are the same the orm layer accesses, so a simple update ends up normally with entitymanager.flush(); And btw. bindings for hibernate and jpa already are in place... All I can say is a lot of thanks to mario for this, this is a killer... I think he has found the right mix of exposing the api and trying to automate. Seam while being excellent and Gavin was entirely correct with his approach of keeping the entitymanager open for a conversation, automates and hides way too much for my taste. One example is that it takes away the control how you connect the master and the detail, and in the end breaks the Tomahawk table that way. Gerald Müllan schrieb: Mario, i am feeling very confident that this will be a great addition to MyFaces in the near future. Through many lessons learned, I can admit that using Spring + JSF together makes up a powerful combination. Tying the new Spring/MyFaces-Conversation scope to JSF brings us beneath a seam-approach, but with less burden. I am quite curious about using the sample-app! As i believe, the sandbox stuff will be removed, after fusion will be quite stable. I also agree that it should have been discussed on the list, but ok it is done now. Next time devs should be informed before such a big commit takes place. cheers, Gerald
Re: MyFaces Fusion
Martin Marinschek schrieb: @troubles: just like you should never put component-bindings in session-scope. @Solved in fusion...
Re: MyFaces Fusion
how can I see the result of this work? On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Sorry to jump in here again, I have been playing guinea pig the last week for marios work. All I can say is this thing now is highly usable by now. You can put a view controller under conversation scope (not a shale one yet, you will lose the callbacks) and simply work on the stuff now like you would do in a rich client environment with an EntityManage, Hibernate Session open for the entire conversation. once you hit a point when you want to terminate, you can have the view controller/conversation invalidate itself or restart itself. Also binding component bindings onto such a conversation is taken care of, you can push them into a separate bean which you weave in by a scope of request and aop:scoped-proxy, then you basically get a fresh view onto your backend component bindings at every request. To sum it up, I just almost finished a first full master detail crud ( I have done several details forms before) The master form has about 30 lines of core code, excluding the setters and getters already dealting with dao calling, handling the query part etc... and adding a detail was a matter of one hour of figuring out which patterns work best and a few minutes of implementation handling new update and delete. The objects you work with always are the same the orm layer accesses, so a simple update ends up normally with entitymanager.flush(); And btw. bindings for hibernate and jpa already are in place... All I can say is a lot of thanks to mario for this, this is a killer... I think he has found the right mix of exposing the api and trying to automate. Seam while being excellent and Gavin was entirely correct with his approach of keeping the entitymanager open for a conversation, automates and hides way too much for my taste. One example is that it takes away the control how you connect the master and the detail, and in the end breaks the Tomahawk table that way. Gerald Müllan schrieb: Mario, i am feeling very confident that this will be a great addition to MyFaces in the near future. Through many lessons learned, I can admit that using Spring + JSF together makes up a powerful combination. Tying the new Spring/MyFaces-Conversation scope to JSF brings us beneath a seam-approach, but with less burden. I am quite curious about using the sample-app! As i believe, the sandbox stuff will be removed, after fusion will be quite stable. I also agree that it should have been discussed on the list, but ok it is done now. Next time devs should be informed before such a big commit takes place. cheers, Gerald -- Arash Rajaeeyan
Re: MyFaces Fusion
Arash Rajaeeyan schrieb: how can I see the result of this work? The demos are not quite there yet (mario is working on them) but you can contact me this evening so that I can drop some example code. ;-)
Re: MyFaces Fusion
Ok here is a first small bite:
What we have here is a simple detail conversation
the master gets injected so that we can have work done
after update
but lives in its own conversation
what happens the user id is injected so is the master
(design decision i chose, you probably could get
the affected dataset also from the master if you set it there,
but I wanted to have clear boundaries so i pushed in the uid of the user
and have it reloaded insted of merging it in.
The entire time the form is open the conversation keeps the user and the
db connection
now if you want to save it...
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
flushcurrentUser basically just goes into an entity manager flush
(the Entity Manager is injected by @PersistenceContext somewhere in the
bo layer automatically, fusion + spring takes care of that,
hence theoretically you could go for a seam like approach of injecting
the PersistenceContext directly into the conversation.
anyway, em.flush that is it or em.persist in case of a create
all the time you work on the same user object coming from the entity
manager and having it referenced there.
usermasterview.findUsers();//
refills the master view with new data so that at a back
or go_master situation you have the updated data there
once you are done
Conversation.getCurrentInstance().invalidate();
return go_master;
For simple navigational use cases you can invalidate all open
conversations at once, so that you do not have pending conversations.
If you still run into those, the conversations time out after while.
public class UserDetailView {
UserBO userbo;
User user = new User();
UserMasterView usermasterview;
int userid;
boolean postinitialized = false;
String viewmode = create;
public int getUserid() {
return userid;
}
public void setUserid(int userid) {
this.userid = userid;
if(!postinitialized) {
postInitialize(userid);
}
}
public void setPreinitUserid(int userid) {
postInitialize(userid);
}
public int getPreinitUserid() {
return -1;
}
public void postInitialize(int userid) {
postinitialized = true;
user = userbo.loadUserById(userid);
viewmode = edit;
}
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
public String dogomaster() {
Conversation.getCurrentInstance().invalidate();
return go_master;
}
public void flushCurrentUser() {
userbo.createUpdateUser((User)user);
}
public UserBO getUserbo() {
return userbo;
}
public void setUserbo(UserBO userbo) {
this.userbo = userbo;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
public String getViewmode() {
return viewmode;
}
public void setViewmode(String viewmode) {
this.viewmode = viewmode;
}
public UserMasterView getUsermasterview() {
return usermasterview;
}
public void setUsermasterview(UserMasterView usermasterview) {
this.usermasterview = usermasterview;
}
}
Arash Rajaeeyan schrieb:
how can I see the result of this work?
On 2/27/07, *Werner Punz* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Sorry to jump in here again,
I have been playing guinea pig the last
week for marios work.
All I can say is this thing now is highly usable
by now.
You can put a view controller under conversation scope
(not a shale one yet, you will lose the callbacks)
and simply work on the stuff now like you would do in a rich client
environment with an EntityManage, Hibernate Session open for the entire
conversation.
once you hit a point when you want to terminate, you can have the view
controller/conversation invalidate itself or restart itself.
Also binding component bindings onto such a conversation is taken care
of, you can push them into a separate bean which you weave in by
a scope of request and aop:scoped-proxy, then you basically get a fresh
view onto your backend component bindings at every request.
To sum it up, I just almost finished a first full master detail crud
( I have done several details forms before)
The master form has about 30 lines of core code, excluding the setters
and getters already dealting with dao calling, handling the query part
etc... and adding a detail was a matter of one hour of figuring out
which patterns work best and a few minutes of implementation
handling new update and delete.
Re: MyFaces Fusion
Additon,
so that you can see that there is nothing hidden in the dao and bo
layers which hides complexity:
dao:
public User createUpdateUser(User user) {
if(!getEm().contains(user) user.getId() == null)
getEm().persist(user);
//we flush here because the user already exists
//since we apply conversations here no merge is needed anymore
getEm().flush();
return user;
return null;
}
bo:
@Transactional
public User createUpdateUser(User user) {
return userdao.createUpdateUser(user);
}
the bo weaves a transaction and calls the dao
the dao flushes in edit cases
and persists in create
in case of a lost entity we bomb out with an exception and a roollback
but i have yet to see that case.
of course all this can be combined into one conversation like seam does
it in its examples, but I opted for the dao bo pattern.
Werner Punz schrieb:
Ok here is a first small bite:
What we have here is a simple detail conversation
the master gets injected so that we can have work done
after update
but lives in its own conversation
what happens the user id is injected so is the master
(design decision i chose, you probably could get
the affected dataset also from the master if you set it there,
but I wanted to have clear boundaries so i pushed in the uid of the user
and have it reloaded insted of merging it in.
The entire time the form is open the conversation keeps the user and the
db connection
now if you want to save it...
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
flushcurrentUser basically just goes into an entity manager flush
(the Entity Manager is injected by @PersistenceContext somewhere in the
bo layer automatically, fusion + spring takes care of that,
hence theoretically you could go for a seam like approach of injecting
the PersistenceContext directly into the conversation.
anyway, em.flush that is it or em.persist in case of a create
all the time you work on the same user object coming from the entity
manager and having it referenced there.
usermasterview.findUsers();//
refills the master view with new data so that at a back
or go_master situation you have the updated data there
once you are done
Conversation.getCurrentInstance().invalidate();
return go_master;
For simple navigational use cases you can invalidate all open
conversations at once, so that you do not have pending conversations.
If you still run into those, the conversations time out after while.
public class UserDetailView {
UserBO userbo;
User user = new User();
UserMasterView usermasterview;
int userid;
boolean postinitialized = false;
String viewmode = create;
public int getUserid() {
return userid;
}
public void setUserid(int userid) {
this.userid = userid;
if(!postinitialized) {
postInitialize(userid);
}
}
public void setPreinitUserid(int userid) {
postInitialize(userid);
}
public int getPreinitUserid() {
return -1;
}
public void postInitialize(int userid) {
postinitialized = true;
user = userbo.loadUserById(userid);
viewmode = edit;
}
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
public String dogomaster() {
Conversation.getCurrentInstance().invalidate();
return go_master;
}
public void flushCurrentUser() {
userbo.createUpdateUser((User)user);
}
public UserBO getUserbo() {
return userbo;
}
public void setUserbo(UserBO userbo) {
this.userbo = userbo;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
public String getViewmode() {
return viewmode;
}
public void setViewmode(String viewmode) {
this.viewmode = viewmode;
}
public UserMasterView getUsermasterview() {
return usermasterview;
}
public void setUsermasterview(UserMasterView usermasterview) {
this.usermasterview = usermasterview;
}
}
Arash Rajaeeyan schrieb:
how can I see the result of this work?
On 2/27/07, *Werner Punz* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Sorry to jump in here again,
I have been playing guinea pig the last
week for marios work.
All I can say is this thing now is highly usable
by now.
You can put a view controller under conversation scope
(not a
Re: MyFaces Fusion
Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario
Re: MyFaces Fusion Naming
So from MY legal point of view MyFaces Fusion is safe as long as we assure that the official name of the library contains the name MyFaces too. quick note, that is should be Apache MyFaces Fusion instead of just MyFaces Fusion What do you think? Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
I personally like fusion Mario Ivankovits schrieb: Hi! Ok, I'll start the naming question now. My personal favorit for the new library still is MyFaces Fusion, for what I have seen on the Internet and the United States Patent and Trademark Office there is already a oracle product called Oracle Fusion, though, they trademarked the whole phrase. Then the first few hits at googe are: Fusion MX Fusion Software NetObjects Fusion From the top of my head I also remember Adobe Cold Fusion (couldn't find the trademark) So from MY legal point of view MyFaces Fusion is safe as long as we assure that the official name of the library contains the name MyFaces too. What do you think? Ciao, Mario
Re: MyFaces Fusion Naming
Hi Matthias! So from MY legal point of view MyFaces Fusion is safe as long as we assure that the official name of the library contains the name MyFaces too. quick note, that is should be Apache MyFaces Fusion instead of just MyFaces Fusion Right, thanks for the pointer! Ciao, Mario
Re: MyFaces Fusion Naming
Mario Ivankovits schrieb: Hi Matthias! So from MY legal point of view MyFaces Fusion is safe as long as we assure that the official name of the library contains the name MyFaces too. quick note, that is should be Apache MyFaces Fusion instead of just MyFaces Fusion Right, thanks for the pointer! Apache MyFaces Connections?
Re: MyFaces Fusion Naming
Apache MyFaces Sesams ? :-) On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: Hi Matthias! So from MY legal point of view MyFaces Fusion is safe as long as we assure that the official name of the library contains the name MyFaces too. quick note, that is should be Apache MyFaces Fusion instead of just MyFaces Fusion Right, thanks for the pointer! Apache MyFaces Connections? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
Matthias Wessendorf schrieb: Apache MyFaces Sesams ? :-) Apache Vista :-D
Re: MyFaces Fusion Naming
Werner Punz schrieb: Matthias Wessendorf schrieb: Apache MyFaces Sesams ? :-) Apache Vista :-D Now a serious one Apache MyFaces Salida
Re: MyFaces Fusion Naming
Now a serious one Apache MyFaces Salida I like the spanish style - one more: Apache MyFaces Defender In Spanish its something like to hold/to know etc Even in English we can argue we defend against detached objects ;-) Ciao, Mario
Re: MyFaces Fusion Naming
Now a serious one Apache MyFaces Salida I like that one -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion
Werner, Why not add this an example app to the fusion project? On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: how can I see the result of this work? The demos are not quite there yet (mario is working on them) but you can contact me this evening so that I can drop some example code. ;-)
Re: MyFaces Fusion
Mike Kienenberger schrieb: Werner, Why not add this an example app to the fusion project? Problem is i do not know the code rights of the current code I do. I have to clear that up first. But what I am currently doing is following. I code my app which is a bigger than the usual example and use it as a usecase and testing ground für the fusion conversation stuff. I later give back parts of the code and the patterns which worked best to mario so that he can look things up and work the results into his examples. That way the example will have well working patterns. I am thinking of having my app as bigger example (it is small enough) but I have to clear the rights first. In the end either way, the examples should give well working blueprints and good patterns on how to apply everything. Werner
Re: MyFaces Fusion
Ah, Ok. I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Mike Kienenberger schrieb: Werner, Why not add this an example app to the fusion project? Problem is i do not know the code rights of the current code I do. I have to clear that up first. But what I am currently doing is following. I code my app which is a bigger than the usual example and use it as a usecase and testing ground für the fusion conversation stuff. I later give back parts of the code and the patterns which worked best to mario so that he can look things up and work the results into his examples. That way the example will have well working patterns. I am thinking of having my app as bigger example (it is small enough) but I have to clear the rights first. In the end either way, the examples should give well working blueprints and good patterns on how to apply everything. Werner
Re: MyFaces Fusion
thank a lot mario, I have started to give it a try. hope I can learn it fast and write about it soon. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
Mike Kienenberger schrieb: Ah, Ok. I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) Actually no it is a production project, it was kindof risky, the schedule for the project is very tight, I opted for fusion because it saves me a lot of time. But it was a high risk, if I would run into something severe I probably would have had to start from scratch, but so far things have worked out excellently, Mario gave me a lot of support on this, and we both could share ideas on how things have to work, but Mario did the implementation I just did the jpa connector. I personally think, that now the point has been reached that nothing severe should occur anymore and things will go smoothly. All use cases and patterns which can occur are in place and work so far. (How to handle central navigations, how to deal with a master view, with a detail view, what do you need if you want to reconnect everything etc...) This stuff really saves a lot of time, because all the merge problems orm mappers usually have in a request centric context are gone (aka lost entity objects having to be merged again, with failurs 90% of the time), you do not have to map form values and objects into orm objects etc.. It is just load object(s) save objects, done, no matter which nesting depth, with almost no compromises introduced by a web centric context. It is really amazing how smooth things can be once you have a stateful object context to work with. Do something in the detail mask, reload the master mask with one single call. And once you go back or hit the back button all changes are there. At a first look combining master and detail within a single page also should be a non issue, simply amazing, it takes away most of the pain ;-).
Re: MyFaces Fusion Naming
+ 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith
Re: MyFaces Fusion
I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) He is really enthusiastic and an adventurer ;-) Kudos to Werner! Ciao, Mario
Re: MyFaces Fusion Naming
There's no way that Fusion as a web development framework is going to pass legal. It doesn't matter if you call it Fusion, MyFaces Fusion, or Apache Myfaces Fusion. Even if it could (and it can't), why would you want to develop product that would be confused with any of the other fusion web frameworks that already exist? On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith
Re: MyFaces Fusion Naming
+1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith
Re: MyFaces Fusion Naming
Ok, after reading Mikes mail and looking at these sites http://www.adobe.com/products/coldfusion/ http://www.netobjects.com/index.html I must revert my previous vote: -1: Apache MyFaces Fusion -1 : Apache MyFaces Defender -0.9 : Apache MyFaces Salida -0.9 : Apache MyFaces Sesams What about Apache MyFaces Seamless ?! :-) --Manfred On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: +1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith
Re: MyFaces Fusion Naming
On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, after reading Mikes mail and looking at these sites http://www.adobe.com/products/coldfusion/ http://www.netobjects.com/index.html I must revert my previous vote: there is also a Fusion from Oracle. -1: Apache MyFaces Fusion -1 : Apache MyFaces Defender -0.9 : Apache MyFaces Salida -0.9 : Apache MyFaces Sesams What about Apache MyFaces Seamless ?! haha ! my Sesams was just a fun proposal. I don't think we (the ASF) should take names like that :-) --Manfred On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: +1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
Hi Manfred! What about Apache MyFaces Seamless ?! I don't think its a good idea to use anything which sounds like Seam. Seam aims to be much more than I have in mind for Fusion now. See, they integrated stuff to create PDFs lately. I don't wont to suggest - by using nearly the same name - that we provide the same functionality. Even if we do in some areas. Ciao, Mario
Re: MyFaces Fusion Naming
What about Apache MyFaces Seamless ?! +1 --Manfred On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: +1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith -- Dennis Byrne
Re: MyFaces Fusion Naming
Ok here are my serious suggestions: * Apache MyFaces Mergence * Apache MyFaces Accretion * Apache MyFaces Collective I have neither checked for legal issues nor do I know how these names sound for native speakers. But I like project names that are not only names but also describe the idea. --Manfred On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, after reading Mikes mail and looking at these sites http://www.adobe.com/products/coldfusion/ http://www.netobjects.com/index.html I must revert my previous vote: there is also a Fusion from Oracle. -1: Apache MyFaces Fusion -1 : Apache MyFaces Defender -0.9 : Apache MyFaces Salida -0.9 : Apache MyFaces Sesams What about Apache MyFaces Seamless ?! haha ! my Sesams was just a fun proposal. I don't think we (the ASF) should take names like that :-) --Manfred On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: +1: Apache MyFaces Fusion -0.9 : Apache MyFaces Salida -1 : Apache MyFaces Defender -1 : Apache MyFaces Sesams On 2/27/07, Grant Smith [EMAIL PROTECTED] wrote: + 1: Apache MyFaces Fusion - 2 : Apache MyFaces Defender (awful!) +0 : Apache MyFaces Salida (e...) -- Grant Smith -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario
Re: MyFaces Fusion Naming
Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario
Re: MyFaces Fusion Naming
Apache MyFaces Orchestra? --Manfred On 2/27/07, Zubin Wadia [EMAIL PROTECTED] wrote: Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario
Re: MyFaces Fusion Naming
guys, let's collect these names in a jira task. eclipse did that in the past for one for their naming issues and the Trinidad podling did it as well. Also this will give users a change to put in their ideas as well -M On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Apache MyFaces Orchestra? --Manfred On 2/27/07, Zubin Wadia [EMAIL PROTECTED] wrote: Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
I'd suggest Maestro since it focuses on different aspects like orm, view and etc. My other suggestion will be Lamborghini but unfortunately it's taken by a company some time ago:) Cheers, Cagatay On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Apache MyFaces Orchestra? --Manfred On 2/27/07, Zubin Wadia [EMAIL PROTECTED] wrote: Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario
Re: MyFaces Fusion Naming
well... these aren't that easy to use... please consider registered names as a no :-) On 2/27/07, Cagatay Civici [EMAIL PROTECTED] wrote: I'd suggest Maestro since it focuses on different aspects like orm, view and etc. My other suggestion will be Lamborghini but unfortunately it's taken by a company some time ago:) Cheers, Cagatay On 2/27/07, Manfred Geiler [EMAIL PROTECTED] wrote: Apache MyFaces Orchestra? --Manfred On 2/27/07, Zubin Wadia [EMAIL PROTECTED] wrote: Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: - current contenders - names eliminated because On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hey, let's collect these names in a jira task. here we go: https://issues.apache.org/jira/browse/MYFACES-1546 Ciao, Mario
Re: MyFaces Fusion Naming
Dennis Byrne schrieb: What about Apache MyFaces Seamless ?! +1 Definite -1 on that, I do not want to get into a fight with the jboss guys over such a name mario is right, even if we cover certain common grounds, seam has an entirely different scope. After all we have a somewhat rought but mostly good cooperation with the jboss guys We have no need to start another Eclipse like naming issue here.
Re: MyFaces Fusion
nice demo, dose any documentation exist any where to start? (other than this example) On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
Mario Ivankovits schrieb: I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) He is really enthusiastic and an adventurer ;-) It has less to do with adventure more along the lines of having been on a dreadful schedule for the app and having a conversation framework as being the only solution to get things done without killing my nerves and banging my head constantly against the orm layer (I have had enough of that in my life= In the end we get a good testcase for the patterns (and lots of stuff has been readjusted) so in the end it is a win win situation for everyone.
Re: MyFaces Fusion
Hi Arash! nice demo, hehe, dont lie ;-) dose any documentation exist any where to start? (other than this example) Unfortunately no, not yet. But I'll start one soon. Ciao, Mario
Re: MyFaces Fusion Naming
Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario
Re: MyFaces Fusion Naming
This was definitely no serious suggestion. Of course. Therefore the smiley. Sorry if I did not state this clear enough. Of course we all have no interest in any (malicious) allusion [is innuendo a better word?]. Although perhaps every open source community should have enough humor to bear such a thing. Well, on the other hand if someone would start a MyCuterFaces implementation we would not be amused about the name, right? --Manfred On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Dennis Byrne schrieb: What about Apache MyFaces Seamless ?! +1 Definite -1 on that, I do not want to get into a fight with the jboss guys over such a name mario is right, even if we cover certain common grounds, seam has an entirely different scope. After all we have a somewhat rought but mostly good cooperation with the jboss guys We have no need to start another Eclipse like naming issue here.
Re: MyFaces Fusion Naming
I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
+1 for Apache MyFaces Kleber On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion Naming
Hey, let's collect these names in a jira task. here we go: https://issues.apache.org/jira/browse/MYFACES-1546 Ciao, Mario
Re: MyFaces Fusion
just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! nice demo, hehe, dont lie ;-) dose any documentation exist any where to start? (other than this example) Unfortunately no, not yet. But I'll start one soon. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) He is really enthusiastic and an adventurer ;-) It has less to do with adventure more along the lines of having been on a dreadful schedule for the app and having a conversation framework as being the only solution to get things done without killing my nerves and banging my head constantly against the orm layer (I have had enough of that in my life= In the end we get a good testcase for the patterns (and lots of stuff has been readjusted) so in the end it is a win win situation for everyone. Except that you might have been able to save some work by leveraging one of the existing dialog manager solutions (including possibly negotiating feature additions if you needed something that wasn't already supported). Instead, you guys just created another one. Craig
Re: MyFaces Fusion
Craig McClanahan schrieb: Except that you might have been able to save some work by leveraging one of the existing dialog manager solutions (including possibly negotiating feature additions if you needed something that wasn't already supported). Instead, you guys just created another one. It is not quite the same... first of all the conversational stuff is more along the lines of what early seam builds were doing. Having a conversation which also is able to control the orm layer, secondly, it is not a real breakage of existing dialog systems and adding yet another one. This stuff originated in the tag space and now has been moved into spring 2.0 as a showcase of what spring scopes can do. It currently has no configuration whatsoever regarding dialog scopes. It currently is along the lines of an extende flash scope with an added orm controller. In the long run a layer like Shale Dialog can provide is heavily needed to add another layer of possible control (Expecially for clearer Begin and Endconversation control) So I do not see neither fusion as a direct competitor to shale dialog nor to spring webflow, it is more along the lines of a scope provider which in the end can benefit of a more extended configuration based dialog system.
Re: MyFaces Fusion
Arash Rajaeeyan schrieb: just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. If you use seam only for conversational control, yes then you can replace it, but seam has a lot of other added value which sometimes is a good supporting layer sometimes you do not need it, fusion has a dedicated scope, which is not quite the same as seam or currently existing dialog systems (but current dialog systems can use fusion as provider for their scope control, with the added value of getting full orm control as well)
Re: MyFaces Fusion
I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. If you use seam only for conversational control, yes then you can replace it, but seam has a lot of other added value which sometimes is a good supporting layer sometimes you do not need it, fusion has a dedicated scope, which is not quite the same as seam or currently existing dialog systems (but current dialog systems can use fusion as provider for their scope control, with the added value of getting full orm control as well) -- Arash Rajaeeyan
Re: MyFaces Fusion
Arash Rajaeeyan schrieb: I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) Ok what info do you need exactly?
Re: MyFaces Fusion
Hi Arash! just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. O-K I'll try: For the installation you have to configure the conversation scope in spring, for this you could have a look at fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml As might see, the conversation scope is configured using an advice, the persistentContextConversationInterceptor. This interceptor holds the entity manager for a conversation and is responsible to configure the thread. Every bean configured in conversation scope (using scope=conversation) will get a new entity manager. If you used spring before, your knowledge about daos wont change. Each conversation bean has to have the aop:scoped-proxy/ marker. This creates a proxy so that - even if you end a conversation - you can work with this bean - but on an new instance then. You can use the conversation scoped bean directly as your backing bean for the view, this is the common case if you have to deal with a single page only. If you have a wizzard like pageflow you'll typically create a conversation scope bean which you inject into your request scope backing bean then. The method in your conversation bean which will issue an update has to be annotated with @Transactional - you can change your entites in not annotated methods too, but then they are not flushed - the flush is delayed unit a @Transactional method has been invoked. That way the entity manager will issue a commit() at the end of the method. Tha can also be the point where you end a conversation, from within the conversation bean you can access the current conversation using Conversation.getCurrentInstance() The conversation can also be invalidated(), which means the next access to the bean instance will see an new empty one. There are strategies to restart a conversation too. The point is that you use the (well known) strategies of spring to get access to the entity manager, and in JPA they are the standardized. Fusion just configures spring so that it will see the associated entityManager for the to-be-invoked conversation. I am not sure if I manged to make things clearer now - all in all its the spring configuration which you have to make correct, afterwards there are just a handful of patterns which you should follow to make the most use out of fusion. Ciao, Mario
Re: MyFaces Fusion
Thanks mario, (and Werner) thats this is more than enough! On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. O-K I'll try: For the installation you have to configure the conversation scope in spring, for this you could have a look at fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml As might see, the conversation scope is configured using an advice, the persistentContextConversationInterceptor. This interceptor holds the entity manager for a conversation and is responsible to configure the thread. Every bean configured in conversation scope (using scope=conversation) will get a new entity manager. If you used spring before, your knowledge about daos wont change. Each conversation bean has to have the aop:scoped-proxy/ marker. This creates a proxy so that - even if you end a conversation - you can work with this bean - but on an new instance then. You can use the conversation scoped bean directly as your backing bean for the view, this is the common case if you have to deal with a single page only. If you have a wizzard like pageflow you'll typically create a conversation scope bean which you inject into your request scope backing bean then. The method in your conversation bean which will issue an update has to be annotated with @Transactional - you can change your entites in not annotated methods too, but then they are not flushed - the flush is delayed unit a @Transactional method has been invoked. That way the entity manager will issue a commit() at the end of the method. Tha can also be the point where you end a conversation, from within the conversation bean you can access the current conversation using Conversation.getCurrentInstance() The conversation can also be invalidated(), which means the next access to the bean instance will see an new empty one. There are strategies to restart a conversation too. The point is that you use the (well known) strategies of spring to get access to the entity manager, and in JPA they are the standardized. Fusion just configures spring so that it will see the associated entityManager for the to-be-invoked conversation. I am not sure if I manged to make things clearer now - all in all its the spring configuration which you have to make correct, afterwards there are just a handful of patterns which you should follow to make the most use out of fusion. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) Don't forget about the conversation scope implementation in Trinidad, too :-). Craig
Re: MyFaces Fusion
oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? On 2/28/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) Don't forget about the conversation scope implementation in Trinidad, too :-). Craig -- Arash Rajaeeyan
Re: MyFaces Fusion
Aaresh feel free to contact me via gtalk if you need help. I am pretty far along in my app already, I have covered most usecases you run into a typical app. Werner Arash Rajaeeyan schrieb: Thanks mario, (and Werner) thats this is more than enough! On 2/28/07, *Mario Ivankovits* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Arash! just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. O-K I'll try: For the installation you have to configure the conversation scope in spring, for this you could have a look at fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml As might see, the conversation scope is configured using an advice, the persistentContextConversationInterceptor. This interceptor holds the entity manager for a conversation and is responsible to configure the thread. Every bean configured in conversation scope (using scope=conversation) will get a new entity manager. If you used spring before, your knowledge about daos wont change. Each conversation bean has to have the aop:scoped-proxy/ marker. This creates a proxy so that - even if you end a conversation - you can work with this bean - but on an new instance then. You can use the conversation scoped bean directly as your backing bean for the view, this is the common case if you have to deal with a single page only. If you have a wizzard like pageflow you'll typically create a conversation scope bean which you inject into your request scope backing bean then. The method in your conversation bean which will issue an update has to be annotated with @Transactional - you can change your entites in not annotated methods too, but then they are not flushed - the flush is delayed unit a @Transactional method has been invoked. That way the entity manager will issue a commit() at the end of the method. Tha can also be the point where you end a conversation, from within the conversation bean you can access the current conversation using Conversation.getCurrentInstance() The conversation can also be invalidated(), which means the next access to the bean instance will see an new empty one. There are strategies to restart a conversation too. The point is that you use the (well known) strategies of spring to get access to the entity manager, and in JPA they are the standardized. Fusion just configures spring so that it will see the associated entityManager for the to-be-invoked conversation. I am not sure if I manged to make things clearer now - all in all its the spring configuration which you have to make correct, afterwards there are just a handful of patterns which you should follow to make the most use out of fusion. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? EG discussions on JSR-299 have started (although it's been quiet for a while), but there's no definitive conclusion on this or pretty much any other technical issue yet. Craig
Re: MyFaces Fusion
Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario
Re: MyFaces Fusion
Hi Mario, In the meantime I'll start digging the codebase and hopefully reach a level where I can start to contribute soon:) Cheers, Cagatay On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario
Re: MyFaces Fusion
Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion
I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
Re: MyFaces Fusion
Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion
I can send a working copy to your private email. if you want. zubin is going to use it in his book. I am changing it each day to make it easier for developers learning MyFaces. On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: MyFaces Fusion
Hi Arash! It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. Yep, I am working on it ... should be available soonish. Ciao, Mario
Re: MyFaces Fusion
On 2/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Some of us reviewed it (offlist) and we came to the conclusion that it has enough power to live as separate project. In the future, please remember that such reviews and conclusions *must* be made on the mailing list. As to the actual merits of the subproject, I don't understand what value it adds to have this in both the sandbox and in fusion.How do the two subprojects differ? Is it just a matter of different dependencies?
