You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mike Kienenberger <mk...@gmail.com> on 2007/03/30 03:15:26 UTC
Re: In response to : Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
Well, you should be asking about this on the myfaces dev mailing list,
so I'm cc'ing my response there.
My personal opinion is that any table functionality should be merged
into the existing t:dataTable. We want to have one component that
can do everything rather than a bunch of different components that can
only do a few things. This is why we have merged t:newspaperTable
functionality into t:dataTable. At minimum, it should be a subclass of
the existing t:dataTable.
On 3/29/07, Jihoon Kim <ji...@gmail.com> wrote:
> Oh one more question while I am at it. After much help from
> you and Gerald I think my code looks a bit okay in possibly being
> reviewed as a candidate for sandbox, so was wondering if I should
> simply wait now until someone takes a look at it? Thanks again and
> till later.
Re: In response to : Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
Posted by Jihoon Kim <ji...@gmail.com>.
First I just wanted to say huge thanks to Gerald for all his helps in
helping me and guiding me in making the patch, as the original version
would have made people go "huh?" on their first look.
But with much of his one on one email helpS I have reduced the number
of components to 4 [DynamicTable, DynamicRow, DynamicColumn, and
DynamicCell] and made the patch more appealing =].
As I wait for a decision of whether these components are suitable for
the sandbox, I will write up better sample examples and work to
improve the component's implementations. once again thanks to Gerald
for helping me and guiding me beyond the instructions I learned from
the Wiki pages and thanks to Mike for deleting the previous
attachments [must have been a grueling task]. Till later.
Regards,
Ji
On 3/30/07, Gerald Müllan <gm...@apache.org> wrote:
> I had a look at the contribution in one of the first versions and it
> was really hard to understand the interactions of the huge amount
> (about 10) of components and the implementation in the view (even in
> the provided example page).
>
> After helping little bit out and giving some hints it looks like
> jihoon has reduced much of the complexity of using it`s contribution
> and it would be a pity if we leave it out.
>
> Don`t really know if it would be that reasonable to put the
> functionality to dataTable (not really possible anymore). In fact, the
> component is that much overloaded with features that
> any more additions will not be helpful for using it.
>
> But, anyway, i dont`t really like the provided example page, it is a
> huge mix of old-fashioned
> java-in-view-code and makes a usage of the component really hard to understand.
>
> What about committing the contribution (CLA has been sent), and
> waiting for a more clarifying example-page? It´s just sandbox, so we
> will see what comes out of it.
>
> Apart from this, many thanks to jihoon for volunteering and this nice
> contribution,
>
> cheers,
>
> Gerald
>
> On 3/30/07, Jihoon Kim <ji...@gmail.com> wrote:
> > I too thought originally to try and develop using the existing
> > dataTable, since that would minimize possible bugs and issues and also
> > minimize the learning curve of learning the new components. However,
> > as what I tried to do is create a one to one mapping between a
> > DynamicTable component to Javascript TableStructure Object, I decided
> > in the end to create separate components.
> >
> > I know it has some of its bad sides, meaning that dynamicTable can
> > have only dynamicColumn [in similar usage method as the column
> > component] or dynamicRow [to allow layering of the components
> > horizontally] and that dynamicColumn and dynamicRow can ONLY have
> > dynamicCell as their child components, but I hoped that some of the
> > pros could outweigh its cons.
> >
> > Pros being self management of the table on the client side without
> > refreshing the page, such as:
> >
> > (1) moving up and down the position within the table via key +
> > mouse with the table refreshing its look without refreshing the
> > page after going beyond
> > the last row of the table
> > (2) dynamic sorting taken place as a function of the javascript object
> > (3) single and multi-select cut, paste, delete, and undelete of the rows
> > (4) dynamic search on the currently sorted column
> > (5) changing the current viewing list with an another [shown in the example]
> > (6) changing the size of the table [namely # of rows]
> > (7) paging capability that is dynamically modified
> > (8) and others if I forgot to mention
> >
> > With some of the possible values for the dynamicCells being :
> > text, textarea, image, select, span, and etceteras
> >
> > I know it was a risky thing, but figured I had nothing to lose so
> > started developing hoping that it might possibly be accepted as a
> > component and in the worst case I figured I might learn something from
> > the development =].
> >
> > Anyway thanks for all the helps to both, I truly appreciated it!!!!!
> >
> > On 3/29/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > > Well, you should be asking about this on the myfaces dev mailing list,
> > > so I'm cc'ing my response there.
> > >
> > > My personal opinion is that any table functionality should be merged
> > > into the existing t:dataTable. We want to have one component that
> > > can do everything rather than a bunch of different components that can
> > > only do a few things. This is why we have merged t:newspaperTable
> > > functionality into t:dataTable. At minimum, it should be a subclass of
> > > the existing t:dataTable.
> > >
> > > On 3/29/07, Jihoon Kim <ji...@gmail.com> wrote:
> > > > Oh one more question while I am at it. After much help from
> > > > you and Gerald I think my code looks a bit okay in possibly being
> > > > reviewed as a candidate for sandbox, so was wondering if I should
> > > > simply wait now until someone takes a look at it? Thanks again and
> > > > till later.
> > >
> >
>
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: In response to : Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
Posted by Gerald Müllan <gm...@apache.org>.
I had a look at the contribution in one of the first versions and it
was really hard to understand the interactions of the huge amount
(about 10) of components and the implementation in the view (even in
the provided example page).
After helping little bit out and giving some hints it looks like
jihoon has reduced much of the complexity of using it`s contribution
and it would be a pity if we leave it out.
Don`t really know if it would be that reasonable to put the
functionality to dataTable (not really possible anymore). In fact, the
component is that much overloaded with features that
any more additions will not be helpful for using it.
But, anyway, i dont`t really like the provided example page, it is a
huge mix of old-fashioned
java-in-view-code and makes a usage of the component really hard to understand.
What about committing the contribution (CLA has been sent), and
waiting for a more clarifying example-page? It´s just sandbox, so we
will see what comes out of it.
Apart from this, many thanks to jihoon for volunteering and this nice
contribution,
cheers,
Gerald
On 3/30/07, Jihoon Kim <ji...@gmail.com> wrote:
> I too thought originally to try and develop using the existing
> dataTable, since that would minimize possible bugs and issues and also
> minimize the learning curve of learning the new components. However,
> as what I tried to do is create a one to one mapping between a
> DynamicTable component to Javascript TableStructure Object, I decided
> in the end to create separate components.
>
> I know it has some of its bad sides, meaning that dynamicTable can
> have only dynamicColumn [in similar usage method as the column
> component] or dynamicRow [to allow layering of the components
> horizontally] and that dynamicColumn and dynamicRow can ONLY have
> dynamicCell as their child components, but I hoped that some of the
> pros could outweigh its cons.
>
> Pros being self management of the table on the client side without
> refreshing the page, such as:
>
> (1) moving up and down the position within the table via key +
> mouse with the table refreshing its look without refreshing the
> page after going beyond
> the last row of the table
> (2) dynamic sorting taken place as a function of the javascript object
> (3) single and multi-select cut, paste, delete, and undelete of the rows
> (4) dynamic search on the currently sorted column
> (5) changing the current viewing list with an another [shown in the example]
> (6) changing the size of the table [namely # of rows]
> (7) paging capability that is dynamically modified
> (8) and others if I forgot to mention
>
> With some of the possible values for the dynamicCells being :
> text, textarea, image, select, span, and etceteras
>
> I know it was a risky thing, but figured I had nothing to lose so
> started developing hoping that it might possibly be accepted as a
> component and in the worst case I figured I might learn something from
> the development =].
>
> Anyway thanks for all the helps to both, I truly appreciated it!!!!!
>
> On 3/29/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > Well, you should be asking about this on the myfaces dev mailing list,
> > so I'm cc'ing my response there.
> >
> > My personal opinion is that any table functionality should be merged
> > into the existing t:dataTable. We want to have one component that
> > can do everything rather than a bunch of different components that can
> > only do a few things. This is why we have merged t:newspaperTable
> > functionality into t:dataTable. At minimum, it should be a subclass of
> > the existing t:dataTable.
> >
> > On 3/29/07, Jihoon Kim <ji...@gmail.com> wrote:
> > > Oh one more question while I am at it. After much help from
> > > you and Gerald I think my code looks a bit okay in possibly being
> > > reviewed as a candidate for sandbox, so was wondering if I should
> > > simply wait now until someone takes a look at it? Thanks again and
> > > till later.
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: In response to : Request to remove some of the attachments in a specific new component, Jira TOMAHAWK-829
Posted by Jihoon Kim <ji...@gmail.com>.
I too thought originally to try and develop using the existing
dataTable, since that would minimize possible bugs and issues and also
minimize the learning curve of learning the new components. However,
as what I tried to do is create a one to one mapping between a
DynamicTable component to Javascript TableStructure Object, I decided
in the end to create separate components.
I know it has some of its bad sides, meaning that dynamicTable can
have only dynamicColumn [in similar usage method as the column
component] or dynamicRow [to allow layering of the components
horizontally] and that dynamicColumn and dynamicRow can ONLY have
dynamicCell as their child components, but I hoped that some of the
pros could outweigh its cons.
Pros being self management of the table on the client side without
refreshing the page, such as:
(1) moving up and down the position within the table via key +
mouse with the table refreshing its look without refreshing the
page after going beyond
the last row of the table
(2) dynamic sorting taken place as a function of the javascript object
(3) single and multi-select cut, paste, delete, and undelete of the rows
(4) dynamic search on the currently sorted column
(5) changing the current viewing list with an another [shown in the example]
(6) changing the size of the table [namely # of rows]
(7) paging capability that is dynamically modified
(8) and others if I forgot to mention
With some of the possible values for the dynamicCells being :
text, textarea, image, select, span, and etceteras
I know it was a risky thing, but figured I had nothing to lose so
started developing hoping that it might possibly be accepted as a
component and in the worst case I figured I might learn something from
the development =].
Anyway thanks for all the helps to both, I truly appreciated it!!!!!
On 3/29/07, Mike Kienenberger <mk...@gmail.com> wrote:
> Well, you should be asking about this on the myfaces dev mailing list,
> so I'm cc'ing my response there.
>
> My personal opinion is that any table functionality should be merged
> into the existing t:dataTable. We want to have one component that
> can do everything rather than a bunch of different components that can
> only do a few things. This is why we have merged t:newspaperTable
> functionality into t:dataTable. At minimum, it should be a subclass of
> the existing t:dataTable.
>
> On 3/29/07, Jihoon Kim <ji...@gmail.com> wrote:
> > Oh one more question while I am at it. After much help from
> > you and Gerald I think my code looks a bit okay in possibly being
> > reviewed as a candidate for sandbox, so was wondering if I should
> > simply wait now until someone takes a look at it? Thanks again and
> > till later.
>