> database driven webapps may use primary key, but wicket needs to be
> general enough to display lists that are simply any ordered collection.
> the current code works, so we need to consider all aspects of lists
> and listviews to make changes. we really shouldn't restrict a general
> class li
> why doesn't a List work in a ListView exactly?
> I do get that a List in a PageableListView could be a bit improved so
> that you have method like
> getList(start,count). But in a ListView a List could work fine. If
> wrapped in a Model for attach/detach
Because a list is still too broad of a
As far as I know hibernate cannot page transparently, if it could there
would be no need for the pagedlist class with black magic inside. Also,
hibernate should not be the only persistence interface considered, there are
plenty more in use right now that are not as advanced.
I have a couple of con
we've had this conversation at least a couple of times. while it's
possible that wicket listviews could have a better model object somehow
(and then provide an adaptor for existing list-based code), we should be
careful not to go crazy with features we don't really need. less is always
more.
w
why doesn't a List work in a ListView exactly?
I do get that a List in a PageableListView could be a bit improved so
that you have method like
getList(start,count). But in a ListView a List could work fine. If
wrapped in a Model for attach/detach
If we encapsulate that ListViewDataSource in a
I don't really see how you are losing flexibility. In this particular case
all we are doing is replacing the use of List interface with lets say
ListViewDatasource. This is necessary because the List interface doesn't
really work well with the listview. What exactly can you do more by
utilizing a l
Igor Vaynberg wrote:
I think our previous discussion was a bit misunderstood. I was not trying to
replace the imodel interface for the exact reason you mentioned below, what
I was trying to replace is the model object interface which is currently a
list. So instead of casting the model object to
I think our previous discussion was a bit misunderstood. I was not trying to
replace the imodel interface for the exact reason you mentioned below, what
I was trying to replace is the model object interface which is currently a
list. So instead of casting the model object to a list and retrieving d
We're thinking about how specific models (like for ListView) would look
like. Would could have an interface like:
public interface IListModel extends IDetachable
{
List getList(Component component);
void setList(final Component component, List list);
}
And force using that in ListViews.
there is a way
The List can implement IDetachable and then detach will be called.
But this is a bit hidden currently and the attach cycle must completely
be programmed by the developer
(on List.size() or List.get(xx) attach check must be done...)
So on the developer list i just posted a question
Yea, I was wondering why all of a sudden there's no way for me to
supply a detachable list. Will that functionality be replaced?
On 7/23/05, james <[EMAIL PROTECTED]> wrote:
> Hi Johan,
>
> Thanks for the clarification.
>
> Regards,
> James
>
>
>
> ---
Hi Johan,
Thanks for the clarification.
Regards,
James
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everythi
Okay, will do. I plan using this in my current project, so after some
testing with a more complicated application I'll provide the patch.
-Matej
Juergen Donnerstag wrote:
Ok, I agree on this as well. Matej, are you able to provide a patch
(incl. javadoc, formatting, etc.) to add it to wicket-e
It should be:
listItem.setRenderBodyOnly(true);
as the list items are the components that you are actually repeating /
rendering.
Eelco
Ah yes, that works splendidly.
Thanks,
Erik.
---
SF.Net email is sponsored by: Discover Easy L
Ok, I agree on this as well. Matej, are you able to provide a patch
(incl. javadoc, formatting, etc.) to add it to wicket-extension?
Juergen
On 7/23/05, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Eelco Hillenius wrote:
> > Juergen Donnerstag wrote:
> >
> >> we've discussed it already and agreed on
DetachableChoiceList just helps you more in the attach./detach cycle
that you had to do if you want to
attach/deattach youre list (if it was for example a database list)
You just have to implement the onAttach and onDetach if needed (mostly
only the onAttach onDetach calls clear() on youre list)
beta's 1-> x can break api i personally don't care. That happens in
other projects to.
RC everything should be stable.
But if we really need to break one or two things for b2 that we should
do that.
Eelco Hillenius wrote:
Johan Compagner wrote:
b1 doesn't have to be the last beta..
there c
Hi all,
I looked at the source code of wicket. Can anyone tell me what is the difference in usage between DetachableChoiceList and ChoiceList?
Regards,
James
Do you Yahoo!?
New and Improved Yahoo! Mail - 1GB free storage!
Eelco Hillenius wrote:
Juergen Donnerstag wrote:
we've discussed it already and agreed on waiting for Matej to come up
with a first draft to proof that the idea works, and it obviously does
very well.
But I guess I'm the only one, who thinks there must be a better
solution. I guess the reason
Juergen Donnerstag wrote:
we've discussed it already and agreed on waiting for Matej to come up
with a first draft to proof that the idea works, and it obviously does
very well.
But I guess I'm the only one, who thinks there must be a better
solution. I guess the reason why I'm not especially k
Johan Compagner wrote:
b1 doesn't have to be the last beta..
there could be a b2 where we do some other stuff.
Just release it so that people can play with it a bit easier. And then
we will see if we release a RC or one other Beta..
Yes, agreed. We shouldn't have any more API breaks after we
Matej Knopp wrote:
Eelco Hillenius wrote:
Looks nice. It doesn't break the API, right?
No, it doesn't break anything. I wanted to make it as transparent as
possible.
Do you think this should be something that Wicket supports
out-of-the-box, or something that you can use as an add-on (in whic
we've discussed it already and agreed on waiting for Matej to come up
with a first draft to proof that the idea works, and it obviously does
very well.
But I guess I'm the only one, who thinks there must be a better
solution. I guess the reason why I'm not especially keen on the idea
is because it
Eelco Hillenius wrote:
Looks nice. It doesn't break the API, right?
No, it doesn't break anything. I wanted to make it as transparent as
possible.
Do you think this should be something that Wicket supports
out-of-the-box, or something that you can use as an add-on (in which
case we could put i
b1 doesn't have to be the last beta..
there could be a b2 where we do some other stuff.
Just release it so that people can play with it a bit easier. And then
we will see if we release a RC or one other Beta..
just my 2 cents.
johan
Eelco Hillenius wrote:
We plan on releasing 1.1b1 tomorrow
Looks nice. It doesn't break the API, right?
Do you think this should be something that Wicket supports
out-of-the-box, or something that you can use as an add-on (in which
case we could put it in the extensions project).
Eelco
Matej Knopp wrote:
I think the functionality is more important
We plan on releasing 1.1b1 tomorrow (sunday gmt+1 that is). Any last
things that are really important to put in there before we release it?
I'm working on a component reference and when I have time want to finish
the beanedit example. Will not have much time for other things I expect.
What do
Johan Compagner wrote:
i also like the idea that you have one html file, X number of property
files and then at load time of the markup file
for a specific locale the property file for that locale is merged in
to the html. And that html is stored for that locale in the cache.
At least i think
i also like the idea that you have one html file, X number of property
files and then at load time of the markup file
for a specific locale the property file for that locale is merged in to
the html. And that html is stored for that locale in the cache.
At least i think tht is the complete idea?
I think the functionality is more important that the actual source code.
This example was supposed to be a simple one.
It certainly can be implemented in a different way than I have done it.
If anyone knows better place where to hook the translation please let me
know.
-Matej
Eelco Hillenius
30 matches
Mail list logo
