You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Werner Punz <we...@gmx.at> on 2005/06/09 01:13:25 UTC
Re: Create a component
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)
Re: Create a component
Posted by Werner Punz <we...@gmx.at>.
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.
Re: Create a component
Posted by Werner Punz <we...@gmx.at>.
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 :-(
Re: Create a component
Posted by John Fallows <jo...@gmail.com>.
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 <br...@yahoo.com> 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 <we...@gmx.at> 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/
>
Re: Create a component
Posted by Brian Abbott <br...@yahoo.com>.
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 <we...@gmx.at> 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/