I only am trying to see if there are other solutions.
Like using an dynamic list model that fires changes to the listview. And then the listview will rebuild itself.
The other thing i can think of is doing it the Swing way. One render component for all the elements in the datamodel,
But i don't think this is possible. And then you would have problems with things that you set on the ui component itself
(for example alternate row coloring)
I do find a removeAll everytime a bit drastic and this could be pretty heavy.
johan
Eelco Hillenius wrote:
What about components like label?
protected void handleBody(final RequestCycle cycle, final MarkupStream markupStream,
final ComponentTag openTag)
{
replaceBody(cycle, markupStream, openTag, getModelObjectAsString());
}
If you set a model like PropertyModel (which was the default behaviour that Jonathan built in), the text to render will be pulled dynamically every time its rendered. I think this works excellent btw; if I would be forced to update the label myself each time my model changes, I would have said goodbye to Wicket a long time ago. I want a framework to help me write less code/ create webapp quicker and more robust, and having to deal with all sorts of observer patterns etc. is not gonna help here imo.
My point is, that the dynamic behaviour is *the* behaviour of all current components *except* for the ListView. To be honest, I had that problem for a longer time allready, but so far hacked around it (see I know for sure now that the current behaviour is really not helping me).
And what about components that you want to develop completely independent. Take for example a components that displays a list of sessions. With a dynamic list, it's easy to create a model that just pulls the list of current sessions from somewhere, and - as the ListView uses this dynamic model - users can just paste in the component without having to worry about chaining observers etc. And... one of the reasons I set up the UI messaging the way I did, is to be able to create a Feedback panel that is able to pull it's info without the need of a lot of coupling configuration. But... currently the feedback panel never updates after it rendered!
Furthermore, if people do not agree with my proposed change, in effect that means that you do not agree with the whole concept of dynamic models. I stress again, this is the way Wicket was set up in the first place, the static models were introduced by Chris and me.
Regards,
Eelco
Johan Compagner wrote:
The problem with a dynamiclist versus static list isn't there in the normal GUI world..
Because then the List has a listener to its modal and it will update the real visual view automaticly for you.
But our listview doesn't have a real datamodel including listener support.
So we have to think about something that is also (almost) not visible for the developer.
so a call to the listview from someplace like listview.dataChanged() which does remove its components
Or and maybe that is the more cleaner way to do it. If you want a dynamic list you have to give listview
a dynamic model, And adds to the model or removed causes the listview to remove the components.
But i currently don't know if this can be done in the current structure.
johan
Martijn Dashorst wrote:
In my experience a user of a ListView (where user equals the developer putting it on a page) is responsible for putting the elements he wants to render in the listview.
So if you have 10 elements in the listview, upon changes in the model, the user has to synchronize it with the contents of the listview. Perhaps this is very oldschool, but not uncommon.
If the listview contains many elements, most list view implementations support the idea of a virtual listview where only those elements that are visible are provided with model data.
I *do* think the concept of a static list versus a dynamic list is very strange and rather uncommon in the visual component world.
List content changes very frequently, and the contents of the model might not be the same elements one wishes to render.
Martijn
Eelco Hillenius wrote:
Hi list,
There's one last issue with ListView currently.
It works with a list that - ofcourse - can have changing contents. A problem exists when the elements changes, especially when the list grows or shrinks. This piece:
// Get the name of the component for listItem i
final String componentName = Integer.toString(lastIndex);
// If this component does not already exist, populate it
ListItem listItem = (ListItem) get(componentName);
if (listItem == null)
{
// Create listItem for index i of the list
listItem = newItem(lastIndex);
populateItem(listItem);
// Add cell to table
add(listItem);
}
Looks up an element and, if it doesn't exists, it creates and populates it. When the contents of the list changed however, the elements that were added to the ListView before are never replaced. Currently, users of ListView have to manually remove the elements of the ListView or create a new one alltogether. In my opinion this is wrong, as it does not allow you to create really independent components. In other words, the ListView can only be used with static lists currently.
I propose to either:
1. add this:
protected void handleRender(final RequestCycle cycle)
{
// force repopulating
removeAll();
so that on every render, the list window will be walked and population will be done, or:
2. implement the above optionally, introducing a boolean property for this usage.
If 2, I additionally need a property name (like 'isStatic' or 'isDynamic'), and we should decide what should be the default behaviour.
Can I have your votes please?
Regards,
Eelco
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
