Re: wicket2 / multi-mounts to class
On 11/16/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> what a stupid thing to say considering it was probably johan
> that wrote that
> part of the code in the first place. you wont be making any
> friends here
> saying things like these.
i replied to his statement - and if im on a black list cause i critizise
him, so it be.
we dont have a black list. in my book you have lost proverbial "notch".
i dont know if he wrote that or did it as i never made him
resonsible for that, the thing i dont like is this eternal "and will stay"
-
he spent a lot of time trying to explain to you the reasons for this - you
just refuse to listen because this broken functionality worked in your very
particular usecase.
in the end there is nothing wrong with a committer telling you that the api
will stay the way it is. we are the ones working on it, so we make the
decisions. we try to be as accomodating as possible, but when n00b users ask
for what we think will do more harm then good we are free to say no.
of course you are free to fork wicket if you do not like how we run it.
you used that api in a way it was not meant to be used. it is
> "lucky" that
> it worked for you because it was not our intention to make
> your usecase
> work. this why we stripped this functionality. btw, it was
> stripped way
> before you showed up or someone tried to do what you did.
maybe it wasnt meant for this... the internet wasnt meant to be what its
today, so should we strip it away?
(yes, this was polemic but is near to the point)
huh?
in the end i think what you want can be implemented if you
> have the ability
> to mount the homepage on "/" with the index coding strategy. coding
> strategies for the homepage or "/" is not something we
> support right now. so
> if you think this will solve your usecase add an rfe to the jira.
this point is now what i call constructive - in the thread i got no
solution
or anything mentioned near to that, but a "no", "dont work" etc.
what you got was an explanation of why what you were doing was wrong. that
is very constructive imho, you just need to listen. dont forget it is not
our job to tell you how to solve your problems - so take any help you can
get.
regarding the "/" mount for the app Home Page: isn't this an JEE antipattern
as the welcome-page should be declared in web.xml?
"/" is relative to your servlet mapping not the "context/" unless you map it
that way - it is up to you.
-igor
regards
Korbinian
>
> -igor
>
> > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Donnerstag, 16. November 2006 14:50
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: wicket2 / multi-mounts to class
> > >
> > > > so you manually change your link to be at the mountpoint...
> > >
> > >
> > >
> > > Where do you manually change it?
> > > I was just pointing out that the 2 mount params must be in
> > > sync in wicket else it doesn't work by default. If somebody
> > > makes a mistake an configures it like i said it goes wrong.
> > > The url will be encoded to something that when it is clicked
> > > on will not be decoded.
> > > That why it is dangerous to have the mount(string,coder)
> > > method and why it is removed in wicket 2.0 (and it will
> stay that way)
> > >
> > >
> > > URLs are build like that: preParams / postParams
> > > > while the first part of the preParams is the mountpoint...
> > > >
> > > > i didnt consider it a bug, but a big feature as it also
> allows even
> > > > the most complicated URL creation schemes as well as
> more enhanced
> > > > CodingStrategies
> > >
> > >
> > >
> > > Where do you use your coding strategies then for then?
> > > Because or you don't use it completely for the encoding
> > > (setResponsePage(
> > > Page.class))
> > > or you don't use it complete for the decoding when a
> request comes in.
> > >
> > > mount("/path/to/page2", new
> > > > > BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > > > Page2.class,null));
> > > >
> > > > is IMHO not a mountpoint but a pain - a mountpoint is a "short"
> > > > description
> > > > of what comes to a page
> > > >
> > > > e.g: "/path/" would be enough here... everything of a URL
> > > is logic -
> > > > and that has to be handled by the appropriate class and
> not coded
> > > > fixed into a init function
> > >
> > >
> > >
> > > That was just an example fine we use your example:
> > >
> > > mount("/path", new
> BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > Page2.class,null));
> > >
> > > Still doesn't work at all.
> > > The encode will generate a "/" url (with nothing behind it if
> > > there are no page params) the decode will only accept urls
> > > that starts with "/path"
> > >
> > > johan
> > >
> >
> >
>
AW: wicket2 / multi-mounts to class
> > > That why it is dangerous to have the mount(string,coder)
> method and
> > > why it is removed in wicket 2.0 (and it will stay that way)
> >
> > ok, basically this comes to: you never got it working/ dont
> understand
> > it so stripped it...
>
>
> what a stupid thing to say considering it was probably johan
> that wrote that
> part of the code in the first place. you wont be making any
> friends here
> saying things like these.
i replied to his statement - and if im on a black list cause i critizise
him, so it be. i dont know if he wrote that or did it as i never made him
resonsible for that, the thing i dont like is this eternal "and will stay" -
> you used that api in a way it was not meant to be used. it is
> "lucky" that
> it worked for you because it was not our intention to make
> your usecase
> work. this why we stripped this functionality. btw, it was
> stripped way
> before you showed up or someone tried to do what you did.
maybe it wasnt meant for this... the internet wasnt meant to be what its
today, so should we strip it away?
(yes, this was polemic but is near to the point)
>
> in the end i think what you want can be implemented if you
> have the ability
> to mount the homepage on "/" with the index coding strategy. coding
> strategies for the homepage or "/" is not something we
> support right now. so
> if you think this will solve your usecase add an rfe to the jira.
this point is now what i call constructive - in the thread i got no solution
or anything mentioned near to that, but a "no", "dont work" etc.
regarding the "/" mount for the app Home Page: isn't this an JEE antipattern
as the welcome-page should be declared in web.xml?
regards
Korbinian
>
> -igor
>
> > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Donnerstag, 16. November 2006 14:50
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: wicket2 / multi-mounts to class
> > >
> > > > so you manually change your link to be at the mountpoint...
> > >
> > >
> > >
> > > Where do you manually change it?
> > > I was just pointing out that the 2 mount params must be in
> > > sync in wicket else it doesn't work by default. If somebody
> > > makes a mistake an configures it like i said it goes wrong.
> > > The url will be encoded to something that when it is clicked
> > > on will not be decoded.
> > > That why it is dangerous to have the mount(string,coder)
> > > method and why it is removed in wicket 2.0 (and it will
> stay that way)
> > >
> > >
> > > URLs are build like that: preParams / postParams
> > > > while the first part of the preParams is the mountpoint...
> > > >
> > > > i didnt consider it a bug, but a big feature as it also
> allows even
> > > > the most complicated URL creation schemes as well as
> more enhanced
> > > > CodingStrategies
> > >
> > >
> > >
> > > Where do you use your coding strategies then for then?
> > > Because or you don't use it completely for the encoding
> > > (setResponsePage(
> > > Page.class))
> > > or you don't use it complete for the decoding when a
> request comes in.
> > >
> > > mount("/path/to/page2", new
> > > > > BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > > > Page2.class,null));
> > > >
> > > > is IMHO not a mountpoint but a pain - a mountpoint is a "short"
> > > > description
> > > > of what comes to a page
> > > >
> > > > e.g: "/path/" would be enough here... everything of a URL
> > > is logic -
> > > > and that has to be handled by the appropriate class and
> not coded
> > > > fixed into a init function
> > >
> > >
> > >
> > > That was just an example fine we use your example:
> > >
> > > mount("/path", new
> BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > Page2.class,null));
> > >
> > > Still doesn't work at all.
> > > The encode will generate a "/" url (with nothing behind it if
> > > there are no page params) the decode will only accept urls
> > > that starts with "/path"
> > >
> > > johan
> > >
> >
> >
>
Re: my feedback after using 1.2.x in a real app
Ah, you mean that the key names themselves are too generic. Ok, that is another thing. I'll leave that the to actual developers :) Erik. Alexei Sokolov schreef: I don't agree. At least rename them. Alexei On 11/16/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: You can override keys in any component. Please see here: http://cwiki.apache.org/WICKET/i18n-and-resource-boundles.html Alexei Sokolov wrote: > 1. Please remove 'null' and 'nullValid' properties from > wicket/Application.properties The names are too generic and used by > Dropdown > controls. So that leaves just number 2. Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: my feedback after using 1.2.x in a real app
I don't agree. At least rename them. Alexei On 11/16/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: You can override keys in any component. Please see here: http://cwiki.apache.org/WICKET/i18n-and-resource-boundles.html Alexei Sokolov wrote: > 1. Please remove 'null' and 'nullValid' properties from > wicket/Application.properties The names are too generic and used by > Dropdown > controls. So that leaves just number 2. Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: my feedback after using 1.2.x in a real app
You can override keys in any component. Please see here: http://cwiki.apache.org/WICKET/i18n-and-resource-boundles.html Alexei Sokolov wrote: 1. Please remove 'null' and 'nullValid' properties from wicket/Application.properties The names are too generic and used by Dropdown controls. So that leaves just number 2. Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: my feedback after using 1.2.x in a real app
in 2.0 we recently introduced ComponentBorder and Component.setBorder (ComponentBorder) -igor On 11/16/06, Alexei Sokolov <[EMAIL PROTECTED]> wrote: Hey guys, [...] 3. Please fix borders. It's not natural to use as it is (in 1.2). Let me explain: [...] Alexei
my feedback after using 1.2.x in a real app
Hey guys,
I hope it is not too late to make some minor suggestions for 2.0. I'm sorry,
I noticed that you switched to apache mailing list too late...
1. Please remove 'null' and 'nullValid' properties from
wicket/Application.properties The names are too generic and used by Dropdown
controls.
2. I found that very often I need to display non-empty text in controls with
Null values. For example, when label has null in model object, I had to
display ''. I actually implemented a separate class to do
this. It will be easier if components were reading "null" property from
property files and use them by default (if such property was found, of
course). Component can default to empty string if such property was not
found.
3. Please fix borders. It's not natural to use as it is (in 1.2). Let me
explain:
Instead of doing something like
add(new TextField("txtid").setBorder(new Border(...
or
or add(new TextField("txtid").add(new Border(... /* as you do with behaviors
*/
I have to use
Border border = new Border(...
border.add(new TextField("txtid"));
add(border);
More importantly, html has to be changed: instead of just
I'd say that border is something you should be able to add to the component
without changing components hierarchy.
Alexei
Re: wicket2 / multi-mounts to class
On 11/16/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> That why it is dangerous to have the mount(string,coder)
> method and why it is removed in wicket 2.0 (and it will stay that way)
ok, basically this comes to: you never got it working/ dont understand it
so
stripped it...
what a stupid thing to say considering it was probably johan that wrote that
part of the code in the first place. you wont be making any friends here
saying things like these.
ok if this is your way
as implementors of the framework our primary concern is to make sure our api
is clear for our users. sometimes this means stripping things that we later
realize can be confusing or have a high chance of being error-prone when
used.
- im not discussing this item anyonger, ill use a own implementation and
thats it...
our secondary concern is to leave enough hooks/flexibility in the api so our
users can customize the existing default functionality
but dont wonder if more
people complain if you strip out existent functionality...
you used that api in a way it was not meant to be used. it is "lucky" that
it worked for you because it was not our intention to make your usecase
work. this why we stripped this functionality. btw, it was stripped way
before you showed up or someone tried to do what you did.
in the end i think what you want can be implemented if you have the ability
to mount the homepage on "/" with the index coding strategy. coding
strategies for the homepage or "/" is not something we support right now. so
if you think this will solve your usecase add an rfe to the jira.
-igor
-Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 16. November 2006 14:50
> An: wicket-dev@incubator.apache.org
> Betreff: Re: wicket2 / multi-mounts to class
>
> > so you manually change your link to be at the mountpoint...
>
>
>
> Where do you manually change it?
> I was just pointing out that the 2 mount params must be in
> sync in wicket else it doesn't work by default. If somebody
> makes a mistake an configures it like i said it goes wrong.
> The url will be encoded to something that when it is clicked
> on will not be decoded.
> That why it is dangerous to have the mount(string,coder)
> method and why it is removed in wicket 2.0 (and it will stay that way)
>
>
> URLs are build like that: preParams / postParams
> > while the first part of the preParams is the mountpoint...
> >
> > i didnt consider it a bug, but a big feature as it also allows even
> > the most complicated URL creation schemes as well as more enhanced
> > CodingStrategies
>
>
>
> Where do you use your coding strategies then for then?
> Because or you don't use it completely for the encoding
> (setResponsePage(
> Page.class))
> or you don't use it complete for the decoding when a request comes in.
>
> mount("/path/to/page2", new
> > > BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > Page2.class,null));
> >
> > is IMHO not a mountpoint but a pain - a mountpoint is a "short"
> > description
> > of what comes to a page
> >
> > e.g: "/path/" would be enough here... everything of a URL
> is logic -
> > and that has to be handled by the appropriate class and not coded
> > fixed into a init function
>
>
>
> That was just an example fine we use your example:
>
> mount("/path", new BookmarkablePageRequestTargetUrlCodingStrategy("",
> Page2.class,null));
>
> Still doesn't work at all.
> The encode will generate a "/" url (with nothing behind it if
> there are no page params) the decode will only accept urls
> that starts with "/path"
>
> johan
>
AW: wicket2 / multi-mounts to class
> That why it is dangerous to have the mount(string,coder)
> method and why it is removed in wicket 2.0 (and it will stay that way)
ok, basically this comes to: you never got it working/ dont understand it so
stripped it... ok if this is your way - im not discussing this item any
longer, ill use a own implementation and thats it... but dont wonder if more
people complain if you strip out existent functionality...
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 16. November 2006 14:50
> An: wicket-dev@incubator.apache.org
> Betreff: Re: wicket2 / multi-mounts to class
>
> > so you manually change your link to be at the mountpoint...
>
>
>
> Where do you manually change it?
> I was just pointing out that the 2 mount params must be in
> sync in wicket else it doesn't work by default. If somebody
> makes a mistake an configures it like i said it goes wrong.
> The url will be encoded to something that when it is clicked
> on will not be decoded.
> That why it is dangerous to have the mount(string,coder)
> method and why it is removed in wicket 2.0 (and it will stay that way)
>
>
> URLs are build like that: preParams / postParams
> > while the first part of the preParams is the mountpoint...
> >
> > i didnt consider it a bug, but a big feature as it also allows even
> > the most complicated URL creation schemes as well as more enhanced
> > CodingStrategies
>
>
>
> Where do you use your coding strategies then for then?
> Because or you don't use it completely for the encoding
> (setResponsePage(
> Page.class))
> or you don't use it complete for the decoding when a request comes in.
>
> mount("/path/to/page2", new
> > > BookmarkablePageRequestTargetUrlCodingStrategy("",
> > > Page2.class,null));
> >
> > is IMHO not a mountpoint but a pain - a mountpoint is a "short"
> > description
> > of what comes to a page
> >
> > e.g: "/path/" would be enough here... everything of a URL
> is logic -
> > and that has to be handled by the appropriate class and not coded
> > fixed into a init function
>
>
>
> That was just an example fine we use your example:
>
> mount("/path", new BookmarkablePageRequestTargetUrlCodingStrategy("",
> Page2.class,null));
>
> Still doesn't work at all.
> The encode will generate a "/" url (with nothing behind it if
> there are no page params) the decode will only accept urls
> that starts with "/path"
>
> johan
>
Removing a row from ListView in a form
Hi,
I'm having a very annoying issue with ListView when used in a
form, with reuseItems set. Apply the attached patch to the
wicket-examples: it adds a link to remove an item in the list of
lines in the forminput example. Now start the patched examples
and go to /wicket-examples/forminput.
Click to remove the first line: you will notice that the second
line is removed! That is the first strange thing. Same problem
when removing the second item.
Now another test: replace the first line with value « Hello » and
click to remove the third line. You will notice that the text you
have entered is reset.
Basically I have the feeling that ListView is broken when
reuseItems is set and rows are deleted.
How can we fix that?
We need to allow to use SubmitLink instead of Link to make sure
form values are sent, by creating a removeItem() method extracted
from removeLink().
But this won't be sufficient: ListView currently removes rows and
re-populates them from the model. This clearly means user input
is lost. Parts of ListView must be rewritten, most notably
internalOnAttach(). Also, the rendering of the ListView is based
on the fact that ListItems have an id that reflects the index in
the list. But because the id of a component cannot be changed,
that clearly shows that all components must be created again. The
render() method has to be reworked, so that ListItem ids are
picked from a sequence to have unique values.
Because of the necessary incompatible changes, I think ListView
should be forked, unless there is another Wicket component that
fits the job?
What do you think?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Index: src/main/java/wicket/examples/forminput/FormInput.html
===
--- src/main/java/wicket/examples/forminput/FormInput.html (revision
474721)
+++ src/main/java/wicket/examples/forminput/FormInput.html (working copy)
@@ -33,6 +33,7 @@
+ Remove
Boolean
Index: src/main/java/wicket/examples/forminput/FormInput.java
===
--- src/main/java/wicket/examples/forminput/FormInput.java (revision
474721)
+++ src/main/java/wicket/examples/forminput/FormInput.java (working copy)
@@ -330,6 +330,7 @@
// objects of
// type FormInputModel.Line) using property text.
item.add(new TextField("lineEdit", new
PropertyModel(item.getModel(), "text")));
+ item.add(removeLink("remove", item));
}
}
-}
\ No newline at end of file
+}
Re: wicket2 / multi-mounts to class
so you manually change your link to be at the mountpoint...
Where do you manually change it?
I was just pointing out that the 2 mount params must be in sync in wicket
else it doesn't work by default. If somebody makes a mistake an configures
it like i said
it goes wrong. The url will be encoded to something that when it is clicked
on will not be decoded.
That why it is dangerous to have the mount(string,coder) method and why it
is removed in wicket 2.0
(and it will stay that way)
URLs are build like that: preParams / postParams
while the first part of the preParams is the mountpoint...
i didnt consider it a bug, but a big feature as it also allows even the
most
complicated URL creation schemes as well as more enhanced CodingStrategies
Where do you use your coding strategies then for then?
Because or you don't use it completely for the encoding (setResponsePage(
Page.class))
or you don't use it complete for the decoding when a request comes in.
mount("/path/to/page2", new
> BookmarkablePageRequestTargetUrlCodingStrategy("", Page2.class,null));
is IMHO not a mountpoint but a pain - a mountpoint is a "short"
description
of what comes to a page
e.g: "/path/" would be enough here... everything of a URL is logic - and
that has to be handled by the appropriate class and not coded fixed into a
init function
That was just an example fine we use your example:
mount("/path", new BookmarkablePageRequestTargetUrlCodingStrategy("",
Page2.class,null));
Still doesn't work at all.
The encode will generate a "/" url (with nothing behind it if there are no
page params)
the decode will only accept urls that starts with "/path"
johan
AW: wicket2 / multi-mounts to class
yeah, but you forgot to put the appropriate first (and following) page param
to it:
"/path/to/page2" -> these are the prePageParams for me here, that i grab
each time i use a new one...
so you manually change your link to be at the mountpoint...
URLs are build like that: preParams / postParams
while the first part of the preParams is the mountpoint...
i didnt consider it a bug, but a big feature as it also allows even the most
complicated URL creation schemes as well as more enhanced CodingStrategies
regards
PS:
mount("/path/to/page2", new
> BookmarkablePageRequestTargetUrlCodingStrategy("", Page2.class,null));
is IMHO not a mountpoint but a pain - a mountpoint is a "short" description
of what comes to a page
e.g: "/path/" would be enough here... everything of a URL is logic - and
that has to be handled by the appropriate class and not coded fixed into a
init function
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 16. November 2006 00:06
> An: wicket-dev@incubator.apache.org
> Betreff: Re: wicket2 / multi-mounts to class
>
> If that works somehow for you then that a bug and should be
> fixed It is not a feature
>
> i just tried it in the nice url example and it is exactly how
> i expected it to happen:
>
> i changed these 2 lines:
>
> //mountBookmarkablePage("/a/nice/path/to/the/first/page",
> Page1.class);
> //mountBookmarkablePage("/path/to/page2.html", Page2.class);
>
> into this:
>
> mount("/path/to/page2", new
> BookmarkablePageRequestTargetUrlCodingStrategy("", Page2.class,null));
> mount("/other/to/page1", new
> BookmarkablePageRequestTargetUrlCodingStrategy("/other2/to/page1",
> Page1.class,null));
>
> and what a suprice
> the link to page2 is just to root of the webapp (so clicking
> on the page2 link will just give me the index/homepage of the
> niceurl example) clicking on page1 will give me an error page
> ofcourse HTTP Status 404 -
> --
>
> *type* Status report
>
> *message*
>
> *description* *The requested resource () is not available.*
>
>
> And this is also logical ofcourse because the url that is generated:
> /other2/to/page1 can't be resolved because there is no mount
> path resolving to that.
>
> johan
>
>
>
> On 11/15/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > > It just has to be in sync. So thats why i removed that
> param in the
> > > mount.
> >
> > thats the point !
> >
> > currently you can take it out of sync in wicket 1.2.x if you want -
> > while in 2.0 you're forbidden to do so -> loss of functionality
> >
> > the thing that i do is to hold a (pre)PageParam in my
> session and add
> > it at the beginning of the params
> >
> > e.g: params = (somesession)getSession().getNewParams;
> > params.add(Integer.toString(params.size()),"foo");
> > while in the session the params are hold all over - so i
> can initalize
> > language and have it before the page, letting the website urls look
> > multilanguaged
> >
> > e.g:
> > /en/index
> > /de/index
> > /fr/index
> >
> > if you look at a URL paradigm then it has a preParameter, a
> Page and a
> > postParameter
> >
> > -> /pre/page/post
> > so what i do is to hook on the pre Part and mount it to it,
> the page
> > is a category-key from the database and the post-params are further
> > config params to it
> >
> > > So i your case it is very strange that it works (as you say i
> > > haven't tested
> > > it)
> > > because you do this:
> > >
> > > mount("/en",new IndexedParamUrlCodingStrategy("",Katalog.class));
> >
> > well - its strange but it works. I can send you a small
> demoApp if you
> > would like to see, and i really like the paradigm where the
> URL is as
> > clear as possible... and by using a config singleton i can find out
> > everytime in every component wich param is good for it (as
> all numbers
> > in that way are relative to the ones you specify in the prePart)
> >
> > Regards
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Mittwoch, 15. November 2006 22:22
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: wicket2 / multi-mounts to class
> > >
> > > no you didn't understand it.
> > >
> > > If you don't have exactly the same parameter in this call:
> > >
> > > mount("/de",new
> IndexedParamUrlCodingStrategy("/de",Katalog.class));
> > >
> > > So if it was this:
> > >
> > > mount("/en",new
> IndexedParamUrlCodingStrategy("/de",Katalog.class));
> > >
> > > Then it doesn't work. The request target will generate an
> url that
> > > will start with "/de"
> > > but incomming request that now have a path "/de/" don't match
> > > with the "/en" key where the strategy is mapped on. So it does't
> > > match.
> > >
> > >
> > > So i your case it is very strange that it works (as you say i
> > > haven't tested
> > > it)
> > > because you do this:
> > >
> >
Re: Wicket wiki, Hibernate
On the Wiki, see [1] The "Other projects related to Wicket" section of the index [2] The "Reference Library/Database Interaction" section [3] The "Documentation Index/Code as documentation" section which cover the many & various Hibernate/iBATIS/etc persistance options. /Gwyn [1] http://cwiki.apache.org/WICKET/#Index-OtherprojectsrelatedtoWicket [2] http://cwiki.apache.org/WICKET/database-interaction.html [3] http://cwiki.apache.org/WICKET/documentation-index.html#DocumentationIndex-Codeasdocumentation On 16/11/06, Sean C. Sullivan <[EMAIL PROTECTED]> wrote: I looked in the Wicket wiki and I did not see any information about Hibernate: http://cwiki.apache.org/WICKET/ Are there best practices for using Hibernate with Wicket? Where can I find these best practices? Sean -- Download Wicket 1.2.3 now! - http://wicketframework.org
Re: License headers v2
On 11/16/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: These are public domain, taken from Doug Lea's concurrent utils. Sun has adopted these for Java 1.5. So for 1.x they need to be there, 2.0 they could be removed in favor of the JDK provided java.util.concurrent collections. I don't know how public domain needs to be treated, i.e. if/when we can put the Apache license header on it or not. Or perhaps just let it stay and but it in NOTICE.
Re: License headers v2
src/main/java/wicket/util/concurrent/ConcurrentReaderHashMap.java (SUN) src/main/java/wicket/util/concurrent/ConcurrentHashMap.java (SUN) src/main/java/wicket/util/concurrent/CopyOnWriteArrayList.java (SUN) These are public domain, taken from Doug Lea's concurrent utils. Sun has adopted these for Java 1.5. So for 1.x they need to be there, 2.0 they could be removed in favor of the JDK provided java.util.concurrent collections. I don't know how public domain needs to be treated, i.e. if/when we can put the Apache license header on it or not. Martijn On 11/16/06, Frank Bille <[EMAIL PROTECTED]> wrote: All, I was a little too quick placing ASL2 headers in all the .java files in 2.0. When looking trough 1.x I found some thirdparty code. I have therefore looked through all java files which doesn't have a ASL2 header but something else and the following came up: src/main/java/wicket/protocol/http/ClientProperties.java (MPL/GPL/LGPL) src/main/java/wicket/util/concurrent/ConcurrentReaderHashMap.java (SUN) src/main/java/wicket/util/concurrent/ConcurrentHashMap.java (SUN) src/main/java/wicket/util/concurrent/CopyOnWriteArrayList.java (SUN) What do we do with these? I'm still not a license expert but the first one sounds "dangerous". Upayavira: I have added a notice about some ASL1.1 software in our NOTICE. Does it look ok? http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/NOTICE.txt?revision=475442&pathrev=475442 Frank -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
License headers v2
All, I was a little too quick placing ASL2 headers in all the .java files in 2.0. When looking trough 1.x I found some thirdparty code. I have therefore looked through all java files which doesn't have a ASL2 header but something else and the following came up: src/main/java/wicket/protocol/http/ClientProperties.java (MPL/GPL/LGPL) src/main/java/wicket/util/concurrent/ConcurrentReaderHashMap.java (SUN) src/main/java/wicket/util/concurrent/ConcurrentHashMap.java (SUN) src/main/java/wicket/util/concurrent/CopyOnWriteArrayList.java (SUN) What do we do with these? I'm still not a license expert but the first one sounds "dangerous". Upayavira: I have added a notice about some ASL1.1 software in our NOTICE. Does it look ok? http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/NOTICE.txt?revision=475442&pathrev=475442 Frank
