You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/10/11 20:57:18 UTC
dynamic table columns et al
Hi!
As some of you might know I've developed Faces Freeway [1].
Well, I don't want to say that this project failed, but - beside - its
hard to maintain a documentation, it is also hard to provide a nice
looking, always working fully fledged simple way to the persistence
framework e.g. hibernate.
BUT, there is one thing I'd like to donate to MyFaces.
The GUI Builder.
The GUI Builder is responsible to instrument another component to view
selected properties out of an annotated Bean (EJB3).
I'd like to let speak code (piece of [2]):
<ff:form var="blog" uri="ejb:blog.Blog">
<h:panelGrid id="blog-layout" columns="2" />
</ff:form>
The above simply does the following:
* Lookup a bean by its FQN (=blog.Blog)
* Lookup a child component whose id is blog-layout (That is by
convention. The form's var is "blog", so the target component has to be
"blog-layout")
* invoke the GUI Builder to dynamically add the bean's properties to the
grid (in this case)
At the end, the you'll see a page as if you have written many
outputLabel and input* components.
The same goes for a table (piece of [3]):
<ff:form var="city" uri="ejb:blog.City">
<h:dataTable id="city-layout" var="entity" value="#{city.fc.entities}" rowClasses="tr1,tr2">
<h:column id="data" rendered="false" />
</h:dataTable>
</ff:form>
The same as above, just creates a table header and its columns. The
id="data" column is optional, but allows you to have pre and post columns.
Ok, I hope I made it clear what it do and how it works. Again - I'd
remove any requirement to a persistence framework. It should just do the
dynamic stuff.
The proposed name could be: dynaBean :-) (instead of ff:form)
One possibility I still have on my todo list is to allow the user to
select the properties which should be shown.
This makes sense if you have beans with many properties, but only a
handful of properties are relevant to your customer. Then you can
customize them easily. Maybe also adding "user defined properties" which
are computed at runtime (maybe using BSF) are possible (not yet, but
thats the masterplan)
A factory the user has to provide is responsible to store all this
customization stuff.
Due to its nature this component relies on annotations, well, can work
without, but its more fun. So it has to go to sandbox15 (is it
functional already?)
What do you think?
Ciao,
Mario
[1] http://facesfreeway.l3x.net/
[2] http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Blog.jsp
[3]
http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Cities.jsp
Re: dynamic table columns et al
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Well, I don't want to say that this project failed
Forgot to mention: We already use it in our application.
---
Mario
Re: dynamic table columns et al
Posted by Martin Marinschek <ma...@gmail.com>.
sounds good.
regards,
Martin
On 10/12/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> > I'm not sure about the name for the component - you want to reuse the
> > logo for the component?
> Just an idea. We don't need to.
>
> > I think it should only express what the
> > component is about, not what it's for...
> Ok, so what about: dynaForm
> In fact, thats the class name of the component already.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: dynamic table columns et al
Posted by Mario Ivankovits <ma...@ops.co.at>.
> I'm not sure about the name for the component - you want to reuse the
> logo for the component?
Just an idea. We don't need to.
> I think it should only express what the
> component is about, not what it's for...
Ok, so what about: dynaForm
In fact, thats the class name of the component already.
Ciao,
Mario
Re: dynamic table columns et al
Posted by Martin Marinschek <ma...@gmail.com>.
Ok, that's good to hear. Slimming down generators is always a good idea.
I'm not sure about the name for the component - you want to reuse the
logo for the component? I think it should only express what the
component is about, not what it's for...
regards,
Martin
On 10/12/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> >> So Faces
> >> Freeway is officially declared dead? What a pity...
> >>
> > Na, I don't think so.
> The name of the component could also be: freewayGui
> Then we can reuse the logo we already have.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: dynamic table columns et al
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> So Faces
>> Freeway is officially declared dead? What a pity...
>>
> Na, I don't think so.
The name of the component could also be: freewayGui
Then we can reuse the logo we already have.
Ciao,
Mario
Re: dynamic table columns et al
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> So Faces
> Freeway is officially declared dead? What a pity...
Na, I don't think so. As I said, we use it and my boss is happy with it
as it allows him to do some simple table-editing-data pages.
But I often want to use just the GUI Builder without any automatic
persistence in the background.
It needs a little rework to make this happen (very little for sure), but
then I think it's a useful component for others to.
And its already highly customizable - there are many entry points to
hook in to help the system to make the right decision about the
component to use when it builds the tree.
The reason for this step is simply that there is e.g. Seam, the
conversationTag, maybe the upcoming WebBeans standard and other
solutions helping with persistence.
FacesFreeway never wanted to play at this league.
I plan to rework the persistence helper in FacesFreeway to utilize the
conversationTag. This is just some glue code then.
In the end it should be possible to use any persistence framework.
I think its more likely that FacesFreeway will survive that (slimmed
down) way ...
Ciao,
Mario
Re: dynamic table columns et al
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Mario,
sounds nice - a lot easier than with the cross-data-table. So Faces
Freeway is officially declared dead? What a pity...
regards,
Martin
On 10/11/06, Arash Rajaeeyan <ar...@gmail.com> wrote:
> Hi Mario
> I think this sound pretty much like rubby on rails
> I don't know about other developers
> but I think some people like this kind of components for making rapid web
> site
> some people hate these kind of components because the code is doings lots of
> thing implicitly and the code is not showing those behaviour.
> lets see what Myfaces gods think about this.
>
>
> On 10/11/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> >
> > As some of you might know I've developed Faces Freeway [1].
> > Well, I don't want to say that this project failed, but - beside - its
> > hard to maintain a documentation, it is also hard to provide a nice
> > looking, always working fully fledged simple way to the persistence
> > framework e.g. hibernate.
> >
> > BUT, there is one thing I'd like to donate to MyFaces.
> > The GUI Builder.
> >
> > The GUI Builder is responsible to instrument another component to view
> > selected properties out of an annotated Bean (EJB3).
> >
> > I'd like to let speak code (piece of [2]):
> >
> > <ff:form var="blog" uri="ejb: blog.Blog">
> > <h:panelGrid id="blog-layout" columns="2" />
> > </ff:form>
> >
> > The above simply does the following:
> > * Lookup a bean by its FQN (=blog.Blog)
> > * Lookup a child component whose id is blog-layout (That is by
> > convention. The form's var is "blog", so the target component has to be
> > "blog-layout")
> > * invoke the GUI Builder to dynamically add the bean's properties to the
> > grid (in this case)
> >
> > At the end, the you'll see a page as if you have written many
> > outputLabel and input* components.
> >
> > The same goes for a table (piece of [3]):
> >
> > <ff:form var="city" uri="ejb:blog.City">
> > <h:dataTable id="city-layout" var="entity" value="#{
> city.fc.entities}" rowClasses="tr1,tr2">
> > <h:column id="data" rendered="false" />
> > </h:dataTable>
> > </ff:form>
> >
> > The same as above, just creates a table header and its columns. The
> > id="data" column is optional, but allows you to have pre and post columns.
> >
> > Ok, I hope I made it clear what it do and how it works. Again - I'd
> > remove any requirement to a persistence framework. It should just do the
> > dynamic stuff.
> >
> >
> > The proposed name could be: dynaBean :-) (instead of ff:form)
> >
> > One possibility I still have on my todo list is to allow the user to
> > select the properties which should be shown.
> > This makes sense if you have beans with many properties, but only a
> > handful of properties are relevant to your customer. Then you can
> > customize them easily. Maybe also adding "user defined properties" which
> > are computed at runtime (maybe using BSF) are possible (not yet, but
> > thats the masterplan)
> > A factory the user has to provide is responsible to store all this
> > customization stuff.
> >
> > Due to its nature this component relies on annotations, well, can work
> > without, but its more fun. So it has to go to sandbox15 (is it
> > functional already?)
> >
> >
> > What do you think?
> >
> > Ciao,
> > Mario
> >
> > [1] http://facesfreeway.l3x.net/
> > [2]
> http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Blog.jsp
> > [3]
> >
> http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Cities.jsp
> >
> >
>
>
>
> --
> Arash Rajaeeyan
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: dynamic table columns et al
Posted by Arash Rajaeeyan <ar...@gmail.com>.
Hi Mario
I think this sound pretty much like rubby on rails
I don't know about other developers
but I think some people like this kind of components for making rapid web
site
some people hate these kind of components because the code is doings lots of
thing implicitly and the code is not showing those behaviour.
lets see what Myfaces gods think about this.
On 10/11/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
>
> As some of you might know I've developed Faces Freeway [1].
> Well, I don't want to say that this project failed, but - beside - its
> hard to maintain a documentation, it is also hard to provide a nice
> looking, always working fully fledged simple way to the persistence
> framework e.g. hibernate.
>
> BUT, there is one thing I'd like to donate to MyFaces.
> The GUI Builder.
>
> The GUI Builder is responsible to instrument another component to view
> selected properties out of an annotated Bean (EJB3).
>
> I'd like to let speak code (piece of [2]):
>
> <ff:form var="blog" uri="ejb:blog.Blog">
> <h:panelGrid id="blog-layout" columns="2" />
> </ff:form>
>
> The above simply does the following:
> * Lookup a bean by its FQN (=blog.Blog)
> * Lookup a child component whose id is blog-layout (That is by
> convention. The form's var is "blog", so the target component has to be
> "blog-layout")
> * invoke the GUI Builder to dynamically add the bean's properties to the
> grid (in this case)
>
> At the end, the you'll see a page as if you have written many
> outputLabel and input* components.
>
> The same goes for a table (piece of [3]):
>
> <ff:form var="city" uri="ejb:blog.City">
> <h:dataTable id="city-layout" var="entity" value="#{city.fc.entities}"
> rowClasses="tr1,tr2">
> <h:column id="data" rendered="false" />
> </h:dataTable>
> </ff:form>
>
> The same as above, just creates a table header and its columns. The
> id="data" column is optional, but allows you to have pre and post columns.
>
> Ok, I hope I made it clear what it do and how it works. Again - I'd
> remove any requirement to a persistence framework. It should just do the
> dynamic stuff.
>
>
> The proposed name could be: dynaBean :-) (instead of ff:form)
>
> One possibility I still have on my todo list is to allow the user to
> select the properties which should be shown.
> This makes sense if you have beans with many properties, but only a
> handful of properties are relevant to your customer. Then you can
> customize them easily. Maybe also adding "user defined properties" which
> are computed at runtime (maybe using BSF) are possible (not yet, but
> thats the masterplan)
> A factory the user has to provide is responsible to store all this
> customization stuff.
>
> Due to its nature this component relies on annotations, well, can work
> without, but its more fun. So it has to go to sandbox15 (is it
> functional already?)
>
>
> What do you think?
>
> Ciao,
> Mario
>
> [1] http://facesfreeway.l3x.net/
> [2]
> http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Blog.jsp
> [3]
> http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Cities.jsp
>
>
--
Arash Rajaeeyan