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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
