FAQ
I won't create a component like selectManyShuttle of ADF Component.
Is posible in short time?

--
Mariano G. Petrakovsky
Programmer · Software Factory
AXG Tecnonexo - www.tecnonexo.com

Development facilities:Av. Maipú 1252 8º (C1006ACT) · Buenos Aires ·
Argentina.
Tel.: (54-11) 4878-0005 - Fax: (54-11) 4878-0065.

Headquarters: 1604 Spring Hill Road, Suite 160 Vienna · VA 22182 · USA.
Tel.: (202) 986-7541 - Fax: (202) 787-3891.


· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
· · · ·

Search Discussions

  • Werner Punz at Jun 8, 2005 at 11:15 pm

    Mariano Petrakovsky wrote:
    I won't create a component like selectManyShuttle of ADF Component.
    Is posible in short time?
    Depends on how good you are at the api, have you created components
    already. If not give yourself a few days to learn the componet api and
    to try yourself on a few test components.

    If you dont have the time, checking out the x:aliasBean might solve
    your problem also for the short term.
    (Tiles also might solve your problem)
  • Brian Abbott at Jun 9, 2005 at 12:06 am
    This reminds me of something I was thinking about this
    morning. I will start by saying at the outset that I
    am very new to JSF and have not yet wrapped myself
    entirely around all aspects of the technology.
    However, with what I am familiar with to date, I think
    JSF represents generally a good step for the Java
    Community. Overall, I feel that this was a positive
    step in aggregating framework technologies and
    providing an answer to MS's ASP.NET. However, I think
    we've missed a subtle turn in the road and have since
    been veering down the wrong path.

    JSF needs to go further to encourage users to develop
    their own components and, allow for those components
    to be easily integrated or consumed by JSF Framework
    implementations. With the present situation (AFAIK), I
    have to make a choice on an implementation and am
    limited to the components provided by that
    implementation (unless I develop my own components
    using that framework's APIs). There is no way to use
    ADF components and MyFaces within the same
    JSF-Distribution/Runtime. In other words, I can't run
    ADF and incorporate MyFaces components or, vice-versa.
    (AFAIK)

    I would like to see core frameworks that differentiate
    themselves on backend functionality such as
    performance, configuration techniques, and integration
    capabilities. These frameworks would include only a
    standard set of UI components. Vendors would then
    distribute their more appealing component sets as a
    standalone package. Applications would inform the
    JSF-Implementation about components it wants to load
    and use through its faces-config.xml file. So, perhaps
    I might add the following entries to faces-config.xml:

    <component-set name="AquaHtml" vendor="CompanyX"
    packageFile="ahcomponents.jar">
    <component name="ahCalendar"
    registrationClass="com.companyx.ah.reg.Calendar" />
    </component-set>

    That would then make a new JSF tag available as
    "<prefix:ahCalendar />" where prefix is defined by the
    TLD import directive.

    I think this would create an environment where you
    have fewer JSF implementations but, a much more active
    world of components and component development.

    Thoughts? Can we already do this with JSF? Did I miss
    something?

    Thanks,

    Brian A.


    --- Werner Punz wrote:
    Mariano Petrakovsky wrote:
    I won't create a component like selectManyShuttle
    of ADF Component.
    Is posible in short time?
    Depends on how good you are at the api, have you
    created components
    already. If not give yourself a few days to learn
    the componet api and
    to try yourself on a few test components.

    If you dont have the time, checking out the
    x:aliasBean might solve
    your problem also for the short term.
    (Tiles also might solve your problem)



    __________________________________
    Discover Yahoo!
    Use Yahoo! to plan a weekend, have fun online and more. Check it out!
    http://discover.yahoo.com/
  • John Fallows at Jun 9, 2005 at 12:19 am
    Brian,

    ADF Faces is a set of extensions to the Faces standard and does not
    provide an implementation of the Faces runtime.

    ADF Faces can be used with any compatible implementation of the Faces
    specification, including the Sun RI, and MyFaces. There is a known
    bug in MyFaces that makes an assumption in the ResponseWriter that
    currently breaks ADF Faces.

    http://www.mail-archive.com/dev@myfaces.apache.org/msg01182.html

    This has recently come up again in other discussion threads on this
    mailing list.

    On your point about aggregation - it is fair comment to say that JSF
    needs to go further to simplify the definition of aggregated component
    sets (and renderkits). This is why most people who write components
    simply do not specify a custom renderkit-id, and are automatically
    included with the standard HtmlBasic RenderKit.

    If you wanted to programmatically aggregate a few different RenderKits
    together, you could create an AggregatingRenderKit that is registered
    under its own renderkit id (which would be the default renderkit id
    for the web application) and which then delegates to a defined set of
    other RenderKits (by renderkit id) either in precedence order or via
    some mapping from renderer type to renderkit id.

    Hope this helps.

    Kind Regards,
    John Fallows.
    On 6/9/05, Brian Abbott wrote:
    This reminds me of something I was thinking about this
    morning. I will start by saying at the outset that I
    am very new to JSF and have not yet wrapped myself
    entirely around all aspects of the technology.
    However, with what I am familiar with to date, I think
    JSF represents generally a good step for the Java
    Community. Overall, I feel that this was a positive
    step in aggregating framework technologies and
    providing an answer to MS's ASP.NET. However, I think
    we've missed a subtle turn in the road and have since
    been veering down the wrong path.

    JSF needs to go further to encourage users to develop
    their own components and, allow for those components
    to be easily integrated or consumed by JSF Framework
    implementations. With the present situation (AFAIK), I
    have to make a choice on an implementation and am
    limited to the components provided by that
    implementation (unless I develop my own components
    using that framework's APIs). There is no way to use
    ADF components and MyFaces within the same
    JSF-Distribution/Runtime. In other words, I can't run
    ADF and incorporate MyFaces components or, vice-versa.
    (AFAIK)

    I would like to see core frameworks that differentiate
    themselves on backend functionality such as
    performance, configuration techniques, and integration
    capabilities. These frameworks would include only a
    standard set of UI components. Vendors would then
    distribute their more appealing component sets as a
    standalone package. Applications would inform the
    JSF-Implementation about components it wants to load
    and use through its faces-config.xml file. So, perhaps
    I might add the following entries to faces-config.xml:

    <component-set name="AquaHtml" vendor="CompanyX"
    packageFile="ahcomponents.jar">
    <component name="ahCalendar"
    registrationClass="com.companyx.ah.reg.Calendar" />
    </component-set>

    That would then make a new JSF tag available as
    "<prefix:ahCalendar />" where prefix is defined by the
    TLD import directive.

    I think this would create an environment where you
    have fewer JSF implementations but, a much more active
    world of components and component development.

    Thoughts? Can we already do this with JSF? Did I miss
    something?

    Thanks,

    Brian A.


    --- Werner Punz wrote:
    Mariano Petrakovsky wrote:
    I won't create a component like selectManyShuttle
    of ADF Component.
    Is posible in short time?
    Depends on how good you are at the api, have you
    created components
    already. If not give yourself a few days to learn
    the componet api and
    to try yourself on a few test components.

    If you dont have the time, checking out the
    x:aliasBean might solve
    your problem also for the short term.
    (Tiles also might solve your problem)



    __________________________________
    Discover Yahoo!
    Use Yahoo! to plan a weekend, have fun online and more. Check it out!
    http://discover.yahoo.com/
  • Werner Punz at Jun 9, 2005 at 6:10 am

    John Fallows wrote:


    On your point about aggregation - it is fair comment to say that JSF
    needs to go further to simplify the definition of aggregated component
    sets (and renderkits). This is why most people who write components
    simply do not specify a custom renderkit-id, and are automatically
    included with the standard HtmlBasic RenderKit.
    Not only the definition, once you move away from myfaces to pure
    JSF, you run into many leaks which were left open intentionally
    to give the tool vendors hooks to plugin their own apis/and or
    differentiate themselves, it is the summation of leaks in the specs
    and mechanisms of how to glue things which makes things unneccesary hard
    not a single aspect.

    In the end the JSF people shoot themselves in the foot that way.
    A harder to grasp api makes less people wanting to jump on the
    bandwagon, and less free components and less third party vendors provide
    component packs.

    There is definitely a lot which has to be done on the component side of
    things to simplify things and make that api accessible also for people
    who dont want to dig into a huge config file mess, holes left standing
    intentionally api.

    Same goes for the entire RAD API issue, which was left totally open
    intentionally :-(
  • Werner Punz at Jun 9, 2005 at 6:05 am
    Yes you basically missed something, this seems to be the entire
    intention if the JSF api, to provide a core foundation.
    The mechanism you describe, is one of the few aspects of the component
    API of JSF, I really like, it is called component pack.
    Usually once you have a component pack, you just dump it into your
    WEB-INF/lib and be done with it on the backend side.
    On the client side you just add the include, thats it.

    A component pack is very easy to create once you have the component up
    and running.

    As for the components themselves, they are hard to implement, and with
    hard I mean hard, I never had to deal with an API for ui components
    that was that hard to grasp (And I had to deal with quite a lot)
    I think, the best way to encourage people to write their own components
    would be to simplify things back to a sane level at that part of the API.

    Having a pure client side component mechanism would be a first start.

    Providing a shortcut which can cover 99.9% of all backend cases, would
    also help.

    The current state of affairs, with having to deal with 2 config files (3
    if you dont roll a component pack) and three classes in the worst case
    to roll a single component, and having huge leaks in the base api for
    simple things like data traversal between the tag and the component
    (which Myfaces fortunately delivers but JSF not)
    and having to deal with a mixture of callbacks and config entries for
    binding all this stuff together is simply too hard, to have people hop
    onto the bandwagon.

    What we would need would be to cut away the config file mess (could be
    done via meta tags)
    provide a clear well documented foundation with good helper methods for
    every aspect of component creation at source level and a good set of
    howtos to have people do that stuff.
    Not having to deal with component group... render group etc... mixtures
    on config file and source callback level even would help a lot
    either have that stuff on source level or on config file level, but
    please not on both, that makes things outright confusing.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedJun 8, '05 at 9:10p
activeJun 9, '05 at 6:10a
posts6
users4
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase