You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Darren Hartford <dh...@ghsinc.com> on 2005/06/10 22:52:04 UTC
Java Studio Creator and MyFaces
After reading through the thread on this mailing list, on the JSC
forums, and googling, it seems that it could theoritcally be possible to
simply update the existing myfaces-extensions.jar file with a modified
MANIFEST.MF and sun-faces-config.xml file.
Jar -uf myfaces-extensions.jar META-INF/sun-faces-config.xml
With the 'correct' sun-faces-config.xml, this should alleviate the
IntrospectionError that normally happens. Has anyone created a
sun-faces-config.xml file for use with myfaces-extensions?
-D
Re: Java Studio Creator and MyFaces
Posted by Bruno Aranda <br...@gmail.com>.
Yes, you just plant a seed and the tree will grow if developers water it... ;-)
Bruno
2005/6/10, Craig McClanahan <cr...@gmail.com>:
> On 6/10/05, Darren Hartford <dh...@ghsinc.com> wrote:
> >
> >
> > After reading through the thread on this mailing list, on the JSC forums,
> > and googling, it seems that it could theoritcally be possible to simply
> > update the existing myfaces-extensions.jar file with a modified MANIFEST.MF
> > and sun-faces-config.xml file.
> >
> > Jar -uf myfaces-extensions.jar META-INF/sun-faces-config.xml
> >
>
> If the components themselves obey the other rules listed on Edwin's
> wiki (such as all the component properties having getters and setters
> instead of using the generic attributes capability), that is indeed
> all it should take.
>
> > With the 'correct' sun-faces-config.xml, this should alleviate the
> > IntrospectionError that normally happens. Has anyone created a
> > sun-faces-config.xml file for use with myfaces-extensions?
> >
>
> I'd be happy to assist, but won't have time to do the whole thing.
> Maybe I can do a starter for one or two components as an example, and
> let you guys hammer out the rest of them.
>
> Craig
>
> > -D
>
Re: Datamodel was Re: Java Studio Creator and MyFaces
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan wrote:
> On 6/10/05, Werner Punz <we...@gmx.at> wrote:
>
>>Craig McClanahan wrote:
>>
>>
>>>
>>>Solving these sorts of problems is exactly what the Shale framework
>>>(part of the Struts project) is designed to address. Current starting
>>>point for info is on the wiki (i'm working up the docs for the
>>>website).
>>>
>>>http://wiki.apache.org/struts/StrutsShale
>>>
>>>You'll be interested particularly in the ViewController interface, and
>>>the fact that it gives you event callbacks at the beginning and end of
>>>a view (init and destroy) and well as other events dependent upon
>>>whether you are processing a form submit or not (preprocess and
>>>prerender). Shale presumes that JSF exists, and leverages its front
>>>controller framework rather than treating JSF just as a mechanism for
>>>constructing the view.
>>>
>>>Craig
>>>
>>
>>Thanks for the fast answer, you basically already implemented the
>>approach I was thinking of, great... you saved me lots of work.
>>A question however, could this stuff be moved into some kind of
>>extended datamodel, so that the datamodel implementors do not have
>>to deal with event callbacks into the view controller?
>>
>
>
> I was actually thinking that things would work the other way around
> ... the event callbacks are view lifecycle things that would trigger
> calls in to the datamodel to acquire and release resources. For
> example, if you needed a Hibernate session to grab some data needed to
> render the current page, you might put the acquisition code in
> prerender() and release it in destroy() ... without the session
> needing to be explicitly aware that it is being used this way. A
> datamodel implementation around a Hibernate session ought to be able
> to work the same way -- part of the contract of using it would be to
> call lifecycle methods on the datamodel itself at appropriate times.
>
Well, I think, I was to unprecise, that exactly was my point of
being probably the best way...
:-)
Thanks again for clarification.
Re: Datamodel was Re: Java Studio Creator and MyFaces
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/10/05, Werner Punz <we...@gmx.at> wrote:
> Craig McClanahan wrote:
>
> >
> >
> > Solving these sorts of problems is exactly what the Shale framework
> > (part of the Struts project) is designed to address. Current starting
> > point for info is on the wiki (i'm working up the docs for the
> > website).
> >
> > http://wiki.apache.org/struts/StrutsShale
> >
> > You'll be interested particularly in the ViewController interface, and
> > the fact that it gives you event callbacks at the beginning and end of
> > a view (init and destroy) and well as other events dependent upon
> > whether you are processing a form submit or not (preprocess and
> > prerender). Shale presumes that JSF exists, and leverages its front
> > controller framework rather than treating JSF just as a mechanism for
> > constructing the view.
> >
> > Craig
> >
>
> Thanks for the fast answer, you basically already implemented the
> approach I was thinking of, great... you saved me lots of work.
> A question however, could this stuff be moved into some kind of
> extended datamodel, so that the datamodel implementors do not have
> to deal with event callbacks into the view controller?
>
I was actually thinking that things would work the other way around
... the event callbacks are view lifecycle things that would trigger
calls in to the datamodel to acquire and release resources. For
example, if you needed a Hibernate session to grab some data needed to
render the current page, you might put the acquisition code in
prerender() and release it in destroy() ... without the session
needing to be explicitly aware that it is being used this way. A
datamodel implementation around a Hibernate session ought to be able
to work the same way -- part of the contract of using it would be to
call lifecycle methods on the datamodel itself at appropriate times.
> Shale might be a good place to resolve this issue there.
> Since you already have the base mechanisms in place.
>
> Thanks for your fast answer
>
Gotta do something while my application builds ... even on a fast
machine it's many minutes :-).
> Werner
>
>
Re: Datamodel was Re: Java Studio Creator and MyFaces
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan wrote:
>
>
> Solving these sorts of problems is exactly what the Shale framework
> (part of the Struts project) is designed to address. Current starting
> point for info is on the wiki (i'm working up the docs for the
> website).
>
> http://wiki.apache.org/struts/StrutsShale
>
> You'll be interested particularly in the ViewController interface, and
> the fact that it gives you event callbacks at the beginning and end of
> a view (init and destroy) and well as other events dependent upon
> whether you are processing a form submit or not (preprocess and
> prerender). Shale presumes that JSF exists, and leverages its front
> controller framework rather than treating JSF just as a mechanism for
> constructing the view.
>
> Craig
>
Thanks for the fast answer, you basically already implemented the
approach I was thinking of, great... you saved me lots of work.
A question however, could this stuff be moved into some kind of
extended datamodel, so that the datamodel implementors do not have
to deal with event callbacks into the view controller?
Shale might be a good place to resolve this issue there.
Since you already have the base mechanisms in place.
Thanks for your fast answer
Werner
Re: Datamodel was Re: Java Studio Creator and MyFaces
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/10/05, Werner Punz <we...@gmx.at> wrote:
> Craig McClanahan wrote:
>
> >
> > I'd be happy to assist, but won't have time to do the whole thing.
> > Maybe I can do a starter for one or two components as an example, and
> > let you guys hammer out the rest of them.
> >
> Craig since you are here reading this, I have a question you might be
> able to answer me best.
> I have written a Hibernate Datamodel in the past, I am not totally happy
> with it.
> The problem is following:
> The Datamodel follows the approach you guys layed out in the JSF specs
> of first giving back the total number of datasets and then sending row
> by row.
>
> The main problem I have with this approach is, that I cannot see a
> clear demarkation line between start of request and end of request,
> which would be needed in many cases to get a decent session and
> transaction and and paging in place.
>
> The only way I could see a way out would be over phase listeners which
> sort of could trigger the datamodels at the beginning and and of the
> phases, so that at the beginning the transaction or whatever you have
> could be opened, or even the full page could be read, then the usual
> mechanisms could trigger for and at the end of the request cycle the
> whatever cleanup which is needed could be done.
> Which means some kind of inter application event system (doable, but messy)
>
> Just my question to Craig, or whoever might be able to answer me this,
> is there a better way to do this, without having to delegate such a task
> to a phase listener (I am not totally happy about this approach)
> I must have missed some clear demarkation point the last time I checked
> out the code (I must admit also I was learning JSF back then)
>
>
Solving these sorts of problems is exactly what the Shale framework
(part of the Struts project) is designed to address. Current starting
point for info is on the wiki (i'm working up the docs for the
website).
http://wiki.apache.org/struts/StrutsShale
You'll be interested particularly in the ViewController interface, and
the fact that it gives you event callbacks at the beginning and end of
a view (init and destroy) and well as other events dependent upon
whether you are processing a form submit or not (preprocess and
prerender). Shale presumes that JSF exists, and leverages its front
controller framework rather than treating JSF just as a mechanism for
constructing the view.
Craig
Datamodel was Re: Java Studio Creator and MyFaces
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan wrote:
>
> I'd be happy to assist, but won't have time to do the whole thing.
> Maybe I can do a starter for one or two components as an example, and
> let you guys hammer out the rest of them.
>
Craig since you are here reading this, I have a question you might be
able to answer me best.
I have written a Hibernate Datamodel in the past, I am not totally happy
with it.
The problem is following:
The Datamodel follows the approach you guys layed out in the JSF specs
of first giving back the total number of datasets and then sending row
by row.
The main problem I have with this approach is, that I cannot see a
clear demarkation line between start of request and end of request,
which would be needed in many cases to get a decent session and
transaction and and paging in place.
The only way I could see a way out would be over phase listeners which
sort of could trigger the datamodels at the beginning and and of the
phases, so that at the beginning the transaction or whatever you have
could be opened, or even the full page could be read, then the usual
mechanisms could trigger for and at the end of the request cycle the
whatever cleanup which is needed could be done.
Which means some kind of inter application event system (doable, but messy)
Just my question to Craig, or whoever might be able to answer me this,
is there a better way to do this, without having to delegate such a task
to a phase listener (I am not totally happy about this approach)
I must have missed some clear demarkation point the last time I checked
out the code (I must admit also I was learning JSF back then)
Re: Java Studio Creator and MyFaces
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/10/05, Darren Hartford <dh...@ghsinc.com> wrote:
>
>
> After reading through the thread on this mailing list, on the JSC forums,
> and googling, it seems that it could theoritcally be possible to simply
> update the existing myfaces-extensions.jar file with a modified MANIFEST.MF
> and sun-faces-config.xml file.
>
> Jar -uf myfaces-extensions.jar META-INF/sun-faces-config.xml
>
If the components themselves obey the other rules listed on Edwin's
wiki (such as all the component properties having getters and setters
instead of using the generic attributes capability), that is indeed
all it should take.
> With the 'correct' sun-faces-config.xml, this should alleviate the
> IntrospectionError that normally happens. Has anyone created a
> sun-faces-config.xml file for use with myfaces-extensions?
>
I'd be happy to assist, but won't have time to do the whole thing.
Maybe I can do a starter for one or two components as an example, and
let you guys hammer out the rest of them.
Craig
> -D