Create a component

[Mariano Petrakovsky <mp...@tecnonexo.com>]

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.


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

Re: Create a component

[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

[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

[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

[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/

Re: Create a component

[Werner Punz <we...@gmx.at>]

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)