Then what was Jonathan Locke talking about in this post from August?
http://jroller.com/page/JonathanLocke/20050829
I believe he was talking on a personal note, without thinking through the consequences. His idea of moving it into extensions hasn't been discussed with the other core developers.
Currently the debate on licensing is something I'd like to avoid, as it got pretty heated last time. Needless to say, adding (L)GPL code into the core project will ignite this discussion again, and stifle development.
If he hadn't implied there that a hibernate dependency was possible in
extensions, I wouldn't have started this discussion.
As I said above, I don't think he thought the ramifications through when he wrote that statement.
wicket-stuff works
as the laboratory it's intended to be, but it's not a good place to send
brand new wicket users.
That is currently true, and we are planning to clean house in the project and get proper releases out, and proper documentation for each released project. Note that this is a community effort, and just complaining doesn't help. Write documentation, wiki's, vote for packages, etc.
Look at this page, if it will even load:
http://cvs.sourceforge.net/viewcvs.py/wicket-stuff/#dirlist
(it's a jungle)
I understand that review of the code in contrib.data would be required.
That's just what I'm asking for: review it, merge it with
contrib.database, do whatever you want, but recognize that this stuff is
at least as important as the AJAX integration that you've already put in
to 1.1 . Maybe it won't get you buzz, but it will help you keep programmers.
As you have seen, we have moved the specific AJAX handlers (DOJO and script.aculo.us) to their respective projects in Wicket Stuff. Dojo already has its own presence, and script.aculo.us will follow soon.
Removing external project specific implementations from the core is a good thing. This allows the core developers to work on the core things, and gives people that care about those external projects the opportunity to work inside the community and a chance to give back.
We *DO* care about database related things and also about creating the best possible components for that. We care about having quality projects in both core and stuff. We care about having happy users. We also care about keeping the core clean, focused, small and simple. We care about our valuable spare time.ce.
Balancing these concerns is tricky, and we have to split our precious free time over these concerns. We want to spend our time the way we think it is most valuable to us. For one developer means doing Ajax, for another this means doing xml parsing. Another will work on clustering. We invited the community to help out and work on projects in Wicket Stuff. It is a community effort to flesh out the good projects and promote them into full grown projects.
So to conclude: we will be addressing the wicket-stuff jungle shortly, and we value all contributions our community makes. We think /all/ features of Wicket are equally important.
Help out by pointing out what you like, and don't like, but be more specific than just 'this sucks'. If a class works great for you, tell us. If you miss a class/method/etc. tell us. If you don't like a class, tell us. Which classes do you use? Why/where do you think they can be improved?
Nathan
Martijn Dashorst wrote:
> No,
>
> We won't put a hibernate or spring dependency into extensions. *Maybe*
> the things that are
> in wicket-contrib-data (note the absence of a specific product), but
> there definetely needs to
> be some reviewing of what is good and what is bad before we upgrade
> things into extensions.
>
> The dataview has been drawing some attention on the core development
> team, so that one is
> currently on our horizon.
>
> As for Hibernate/Spring/etc. There are a number of reasons why the won't
> be introduced into core.
>
> On of them is that they are/depend on libraries that are not compatible
> with the Apache licence. One of the reasons
> we created the wicket-stuff project is for that reason. In that project
> any open source licence goes,
> as long as it is stated clearly under which license the component
> (library) is released.
>
> In Wicket core, Apache 2, or compatible licensed code is the only
> license we permit.
>
> Martijn Dashorst
>
>
> On 10/13/05, *Nathan Hamblen* <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> wrote:
>
> Fine. What about extensions?
>
> Phil Kulak wrote:
> > Oh, well, I agree that the hibernate stuff should not be in the core.
> >
> > On 10/13/05, Nathan Hamblen <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> >> One thing I mean by integration is a built-in loadable
> detachable model
> >> for Hibernate mapped objects, like what's in contrib.data and
> >> contrib.database . After that, you need an easy way for people to
> fill up
> >> list views with query results. If there weren't a use for base
> classes
> >> that help in these tasks, the several contributed ones would not
> exist.
> >>
> >> This isn't really a "tier" argument (thank God), it's about giving
> >> people a starting point and suggested structure for accessing a
> database
> >> in a Wicket application. Pretty basic stuff if you ask me, and I
> do not
> >> think that a pile of contributed packages and examples is much of a
> >> solution.
> >>
> >> Nathan
> >>
> >> Nick Heudecker wrote:
> >>> I have to agree with Igor here. I didn't have to do anything
> special
> >>> when I started using Wicket. The DAOs and Service tier that I
> had in
> >>> place worked fine.
> >>>
> >>> It could be argued that if you're integrating Hibernate at the
> Wicket
> >>> level, something is wrong in your design. However, I
> understand that
> >>> for simple apps, multiple tiers is overkill. Things like Spring's
> >>> OpenSessionInViewFilter still work, or you can roll your own
> filter and
> >>> have it set the session in the WebSession.
> >>>
> >>> Perhaps I'm confused on what you mean by integration.
> >>>
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by:
> >> Power Architecture Resource Center: Free content, downloads,
> discussions,
> >> and more. http://solutions.newsforge.com/ibmarch.tmpl
> <http://solutions.newsforge.com/ibmarch.tmpl>
> >> _______________________________________________
> >> Wicket-user mailing list
> >> [email protected]
> <mailto:[email protected] >
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
> discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> <https://lists.sourceforge.net/lists/listinfo/wicket-user >
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
