FAQ

[MyFaces-dev] RE: Re: MyFaces Fusion Naming

Jacob
Feb 28, 2007 at 9:00 pm
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 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
reply

Search Discussions

15 responses

  • Jeff Bischoff at Feb 28, 2007 at 9:04 pm
    In that case, how about:

    Apache Myfaces Spider

    ...as in Spider Webs... obviously, can't use "web" itself :P

    jacob@hookom.net 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 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
  • Mario Ivankovits at Feb 28, 2007 at 9:10 pm
    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
  • Jeff Bischoff at Feb 28, 2007 at 9:15 pm
    Glad you liked it. Yeah I figured it would be pretty common name, but at
    least not as bad as Spyder! (taken by both S&P 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


  • Thomas Spiegl at Feb 28, 2007 at 11:28 pm
    another one ...

    Apache MyFaces Edge
    On 2/28/07, Jeff Bischoff 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 S&P 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
  • Kito D. Mann at Mar 1, 2007 at 7:10 pm
    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
    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 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 S&P 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
  • Mario Ivankovits at Mar 1, 2007 at 8:57 pm
    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
  • Mike Kienenberger at Mar 1, 2007 at 11:43 pm
    Might be significant that two people have asked this question so far :-)
    On 3/1/07, Mario Ivankovits 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 at Mar 2, 2007 at 6:49 am
    and may be thats because shale has chosen a different approach?
    On 3/2/07, Mario Ivankovits 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
  • Werner Punz at Mar 2, 2007 at 1:22 pm

    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.
  • Craig McClanahan at Mar 2, 2007 at 4:40 pm

    On 3/2/07, Werner Punz 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
  • Mario Ivankovits at Mar 2, 2007 at 5:24 pm
    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 at Mar 2, 2007 at 5:46 pm
    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 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
  • Werner Punz at Mar 3, 2007 at 12:33 am

    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.
  • Craig McClanahan at Mar 2, 2007 at 7:07 pm

    On 3/2/07, Mario Ivankovits 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.
    You're right ... he would definitely know :-).
    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.
    My personal feeling is this should really be solved at the servlet spec level.
    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.
    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. That much is
    really easy to do with pretty much any conversation scope API (for
    example, with Shale you'd just define a listener that was notified
    about the start and stop events; with Struts 2 you'd stick this logic
    into an interceptor chain, and so on). I guess that I don't
    understand why supporting the persistence manager that way *required*
    a new kind of conversation paradigm.

    It's more of academic interest to me at the moment (I'm buried in work
    stuff right now) ... but if your conversation scope stuff can be
    adapted to Shale Dialog's dialog manager[1] APIs[2], it'd be pretty
    easy to integrate -- there's already two implementations (basic and
    SCXML based), so the more the merrier.

    Craig

    [1] http://shale.apache.org/shale-dialog/index.html
    [2] http://shale.apache.org/shale-dialog/apidocs/index.html

    Ciao,
    Mario
  • Mario Ivankovits at Mar 2, 2007 at 7:19 pm
    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

Related Discussions