Re: ERROR - DiskPageStore - Error flushing page
What kind of dirs doe jou see in that dir under tomcat? How many entries? Do you have it for all your sessions? Is the filename incorrect? On 16/01/2009, ragu_sree ragu.indiakh...@gmail.com wrote: I am using wicket1.3.5 version only , but still getting the problem , any one please provide me the solution -- View this message in context: http://www.nabble.com/ERROR---DiskPageStoreError-flushing-page-tp21498004p21499158.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: I'm intersted in design
Can i then do this?
Component x = new Component()
parent.add('first', x)
parent.add('second',x)
Or should it then throw an exception at runtime (it wil in develop mode)
And if there are situations that the component wants to know its name
before its added to the parent (in its constructor for example). What
then?
On 16/01/2009, Anton Veretennikov anton.veretenni...@gmail.com wrote:
Because it is imperative in many ways that the component knows it's own
ID.
Look through the code to see how many times it uses it's ID.
Do you mean that instance needs to know ID BEFORE it was added?
If not, add() can internally set ID of component sent as parameter.
If one child can't have other ID it can be checked in setId().
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How to test Ajax Submit Button on A form
Can any one please help me with testing an AjaxSubmitButton on a form. I am using tester.executeAjaxEvent to call the event. But I am not sure how to set the data on the form and submit the data while using an ajax submit button -- View this message in context: http://www.nabble.com/How-to-test-Ajax-Submit-Button-on-A-form-tp21514401p21514401.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RE: Things I miss in Wicket
You could take a look at the Hippo blog project, (follow the README)
http://svn.hippocms.org/repos/hippo/experimental/hippo-blog/trunk
It is composed of a customized CMS and a site web-application.
The cms has the blog document types added as an additional jar to the
standard packaged cms war. The frontend is built with the Hippo site
toolkit, http://www.onehippo.org/site-toolkit, using jsp for the
rendering. (yes, I would love to see a wicket frontend there too!)
The console should make clear what I've hinted to in this thread.
Plugins are configured with nodes in the (jcr) repository, and they are
started and stopped in groups/clusters.
(see /hippo:configuration/hippo:frontend/cms)
It is useful to think of plugins as units of configuration; if a plugin
is evolving to the point where its configuration becomes intimidating,
it's about time to break the plugin up into parts. Conversely, if a set
of plugins needs to be kept closely in sync with their configuration,
they probably aren't as independent as you would like and you're better
off coding it in java.
Coming back to an earlier post: I don't see the web-application
builder happening though; the one where you never need to touch code.
An interesting application will have many components with complex
interactions, by definition. Of course, one should decouple as many
components as possible and make the way they work and hang together
configurable. But the complexity of an application flow is still there
and you have to express it either in configuration or in code. I think
we can all agree that code works better here, or we wouldn't be using
Wicket!
thanks for the interest!
cheers, Frank
On Fri, 2009-01-16 at 20:40 +0100, Tobias Marx wrote:
Great!
Are there any demo/reference websites that run Hippo CMS or Hippo Portal?
Original-Nachricht
Datum: Fri, 16 Jan 2009 16:12:13 +0100
Von: Frank van Lankvelt f.vanlankv...@onehippo.com
An: users@wicket.apache.org
Betreff: RE: Things I miss in Wicket
Sure these kinds of things exist. In Hippo CMS 7, we're nesting panels
that each have their own instance-specific configuration. Different
document types have a corresponding (admittedly quite simple) plugin
configuration that can be edited within the cms. The cms itself is
mostly a (more involved) configuration of such loosely-coupled generic
panels.
This approach is actually opposite to Wickets philosophy (only Java +
HTML). But the great thing about combining opposites is that there is a
sliding scale for doing things. You can start out using the generic
building blocks, giving you limited flexibility in terms of how these
panels can interact, but at least they can be easily configured using a
web interface. Then, as your needs transcend the possibilities of this
simplistic solution, you can write your own plugins with the full power
of Wicket at your disposal.
Cheers, Frank
-Original Message-
From: Tobias Marx [mailto:superoverdr...@gmx.de]
Sent: 16 January 2009 14:10
To: users@wicket.apache.org
Subject: Re: Things I miss in Wicket
Brix only works the way it works because it does not need a
database..with a flexible achitecture and a database this
would not be possible without too many limitations either.
The ultimate goal would be a web-application builder...or at
least a highly configurable website (whatever kind of) that
only needs to be written once and can be customized easily
without changing the code.
So far this does not existthe thing that comes closed is
Typo3, Drupal or something like that...or the Dolphin
community builder - but this is all at a very early stage and
so far starting from scratch is often the better option in
the long-term.
Original-Nachricht
Datum: Fri, 16 Jan 2009 07:59:11 -0500
Von: Richard Allen richard.l.al...@gmail.com
An: users@wicket.apache.org
Betreff: Re: Things I miss in Wicket
What I don't like about Wicket is, that it is like writing normal
Java applications - although rich clients applications are being
replaced
with
web-based solutions and there is a fundamental difference between
web-applications and normal java applications. If you have a java
application as a product, it is normal to employ software
developers
that
work on bug fixes and new features all the time - they constantly
develop
and it is expensiveeverything has to be done by a software
developer.
Being more like a normal Java application (whatever that is :) is
precisely why some of us like Wicket.
An ideal web-application is developed once and the Java code is
never touched again for 3-5 years until there are a lot of new
features necessary but in this time there could be
several small
changes
Clickable rows on DataTable - exceptions on refresh
Hello,
I am trying to extend a data table to be able to respond to clicks
anywhere on the row table:
public interface ClickHandlerT extends Serializable {
public void onClick( ItemT item );
}
public class CustomDataTableT extends DataTableT {
private FilterForm filterForm;
private ISortableDataProviderT dataProvider;
private ClickHandlerT rowClickHandler;
public ClickHandlerT getRowClickHandler() {
return rowClickHandler;
}
public void setRowClickHandler( ClickHandlerT rowClickHandler ) {
this.rowClickHandler = rowClickHandler;
}
public boolean isClickable() {
return rowClickHandler != null;
}
public CustomDataTable( String id, IColumnT[] columns,
ISortableDataProviderT dataProvider, int rowsPerPage,
FilterForm filterForm )
{
super( id, columns, dataProvider, rowsPerPage );
this.dataProvider = dataProvider;
this.filterForm = filterForm;
createToolbars();
}
private void createToolbars() {
addTopToolbar( new NavigationToolbar( this ) );
if ( this.filterForm != null )
addTopToolbar( new FilterToolbar( this, filterForm,
(IFilterStateLocator) dataProvider ) );
addTopToolbar( new HeadersToolbar( this, dataProvider ) );
addBottomToolbar( new NoRecordsToolbar( this ) );
addBottomToolbar( new NavigationToolbar( this ) );
}
public CustomDataTable( String id, IColumnT[] columns,
ISortableDataProviderT dataProvider, int rowsPerPage ) {
this( id, columns, dataProvider, rowsPerPage, null );
}
@Override
protected ItemT newRowItem( String id, int index, IModelT model ) {
return isClickable() ? new ClickableItemT( id, index, model,
rowClickHandler ) : new OddEvenItemT( id,
index, model );
}
}
public class ClickableItemT extends OddEvenItemT implements ILinkListener {
private ClickHandlerT handler;
public ClickableItem( String id, int index, IModelT model,
ClickHandlerT handler ) {
super( id, index, model );
this.handler = handler;
}
@Override
public void onLinkClicked() {
handler.onClick( this );
}
@Override
protected void onComponentTag( ComponentTag tag ) {
super.onComponentTag( tag );
tag.put(onclick,
String.format(
window.location.href='%1$s';return false,
urlFor(
ILinkListener.INTERFACE ) ) );
String cls = clickable;
String currentClass = tag.getAttributes().getString( class );
if ( currentClass != null )
cls += + currentClass;
tag.put(class,
cls );
}
}
Now the problem:
the links created for clicks on table row look like this:
http://localhost/app/properties/wicket:interface/:3:properties:filterForm:dataTable:rows:2::ILinkListener::/
while the url for normal Link is:
http://localhost/app/properties.3.2?wicket:interface=:3:properties:filterForm:dataTable:rows:3:cells:3:cell:edit:2:ILinkListener::
Clicking on the table row makes no redirect. Usually there is a redirect
to: http://localhost/app/properties.3.2
When I hit refresh I get:
WicketMessage: unable to find component with path
properties:filterForm:dataTable:rows:5 on stateless page [Page class =
eu.org.squash.appcomponents.properties.example.PropertiesPage, id = 3,
version = 5, ajax = 0] it could be that the component is inside a
repeater make your component return false in getStatelessHint()
the row index properties:filterForm:dataTable:rows:5 keeps advancing
every time. There are only 2 rows in my test DataTable.
Could anyone comment? Maybe I am simply building the link for the row
incorrectly.
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to test Ajax Submit Button on A form
rag...@directi schrieb: Can any one please help me with testing an AjaxSubmitButton on a form. I am using tester.executeAjaxEvent to call the event. But I am not sure how to set the data on the form and submit the data while using an ajax submit button There is a form tester FormTester ft = _wicketTester.newFormTester(apanel:aform); ft.setValue(componentOnForm, theValue); ... ft.select(componentOnFormSelectable, indexOfValue); ft.submit(); You have to call submit at the end. Otherwise the call of executeAjaxEvent has no data in form. At least the data you've just assigned. Initial data from form are still there if you don't do ft.submit(). HTH Per - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicketstuff-how to contribute
Hi, I know that this question is not directly related to wicket itself but I hope that somebody knows answer J I have updated wicketstuff-lightbox project to be compliant with wicket 1.4-rc1 and I would send my changes back but I cannot find some contact, mail or something about wicketstuff group. Could someone point me where I can find these information? May be I'm really blind.. ;-) Thank you, Vitek
Re: wicketstuff-how to contribute
Wicket stuff is a very relaxed project. Just provide us with your sourceforge.net account name, and we'll add you to the project. Martijn On Sat, Jan 17, 2009 at 4:37 PM, Vitek Tajzich v.tajz...@gmail.com wrote: Hi, I know that this question is not directly related to wicket itself but I hope that somebody knows answer J I have updated wicketstuff-lightbox project to be compliant with wicket 1.4-rc1 and I would send my changes back but I cannot find some contact, mail or something about wicketstuff group. Could someone point me where I can find these information? May be I'm really blind.. ;-) Thank you, Vitek -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket stuff core, archetypes?
i don't completely agree:
- to be searched by nexus, repo needs to be nexus-aware: i.e.
nexus-maven-repository-index.properties and
nexus-maven-repository-index.zip files need to be deployed to the
/.index folder at maven repository root.
we are mainly talking about wicketstuff projects currently hosted in a
non-indexed (nothing at
http://wicketstuff.org/maven/repository/.index/) community-owned repo.
as far as i know, there are no wicket components in maven central
repo.
i insist, so long as wicketstuff is *our repo* we can do whatever we
want with it. we can decide *not to ban* wickethub's crawler (our
crawler). we still can use nexus though, but we're not forced to do so
- moreover, no specific metadata indexed:
Nexus indexer component provides an API to index Maven repository,
merge and download index updates. It also provides an API to search
through registered indexes using various search criteria, including:
* Browse through repository indexes
* Search jars by artifactId and groupId
* Search jars by the packaging type (e.g. to find Maven plugins or
Archetypes)
* Search jars by sha1 (e.g. to identify arbitrary jars with actual
Maven artifacts)
* Search Maven artifacts/jar by class name (e.g. resolve classpath
issues from build errors or class not found exceptions)
...knowing that we need to index specific metadata
(http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata).
by the way, i wouldn't store metadata under META-INF inside the jar; i
would rather include it in the pom file.
let's put an example, let's say we need to display up-to-date url of
screenshots (or examples or whatever)
Screenshots=http://mycomponents.com/slider/screenshots/1.jpg,http://mycomponents.com/slider/screenshots/2.jpg,...
wickethub will somehow need to know about those urls. how could it
grab that out of nexus? i had a look at their lucene api and i'm not
aware of the aforementioned scenario being possible.
wickethub's crawler is a custom solution. it has to be smarter in that
regard - to be able to keep synchronized custom data *we* (but not
everybody) will be using in maven artifacts.
francisco
On Thu, Jan 15, 2009 at 5:37 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
cool. this definitely looks like the right approach to me (assuming it
indexes most of the big repos)
jon
Rodolfo Hansen wrote:
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
you could search for artifacts with the appropriate metadata, or search
inside the jars for some specific file / class (I think)
On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy
francisco.tre...@gmail.com wrote:
wasn't this someone martijn?
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you banned.
i replied
martijn, banning policies are issued by repository owners. i don't
know which repo you're referring to as the maven repository.
central? apache?
i suggested setting up or reusing a repo that would be mainly for
wicket components, and owned by the project/ community. advantages:
- we simply don't ban wickethub's crawler
- we provide guidelines for wicket developers to easily publish their
artifacts (and possibly check if metadata is present, etc)
as for the rest ('non-compliant'), that would be maintained manually
so no crawling involved.
francisco
On Wed, Jan 14, 2009 at 11:40 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
yeah, you really do need a maven expert's help i think. i was chatting
with
someone about this and they said something to the effect of: oh, god
no
don't crawl the maven repo. you'll get banned. so there's some more
official way of doing this apparently.
francisco treacy-2 wrote:
here it is:
http://code.google.com/p/wickethub/ (source code for the
http://wickethub.org/ webapp)
a small piece of code (with not even unit tests so far) but hopefully
the way to start addressing our ideas:
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
http://www.nabble.com/wickethub.org-td20995774.html
let me know if you're interested in contributing. i'd particularly
like to find a maven power-user(s) who'd like to help implementing
some of jon's automatic component repo thingy.
nino, what about the archetypes for wicketstuff?
francisco
On Sat, Dec 20, 2008 at 9:00 PM, Nino Martinez
nino.martinez.w...@gmail.com wrote:
Ahh, no did'nt follow the thing that far, will read up on it now..
Re: wickethub.org
[update]
i have open sourced the wickethub project, an ongoing effort to keep
track of wicket goodies (snippets, plugins, components -- which are
not all necessarily hosted at wicketstuff).
http://code.google.com/p/wickethub/
first version needs to be polished. top features to develop are:
*
http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
(discussion in this thread and
http://www.nabble.com/Wicket-stuff-core%2C-archetypes--td21102842.html)
* better support for labeling / tagging 'modules'
* pastebin for snippets
* full smart lucene search for metadata and content
i'm also keen on design/usability tips (should we call them modules?).
there might be some downtime as i'm moving the webapp to a new server.
if you want to contribute, let me know.
francisco
On Thu, Dec 18, 2008 at 1:54 PM, francisco treacy
francisco.tre...@gmail.com wrote:
martijn, banning policies are issued by repository owners. i don't
know which repo you're referring to as the maven repository.
central? apache?
i suggested setting up or reusing a repo that would be mainly for
wicket components, and owned by the project/ community. advantages:
- we simply don't ban wickethub's crawler
- we provide guidelines for wicket developers to easily publish their
artifacts (and possibly check if metadata is present, etc)
as for the rest ('non-compliant'), that would be maintained manually
so no crawling involved.
francisco
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you banned.
Martijn
On Tue, Dec 16, 2008 at 8:51 PM, francisco treacy
francisco.tre...@gmail.com wrote:
we could cover automatic updates of 'compliant' maven artifacts - and
the rest (non-compliant, svn source code, snippets) maintained
manually.
[ compliant = stick to metadata described here:
http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata
]
from the app side this means developing the discovery process
mentioned in the idea... thread, which seems really feasible.
however to start including the aforementioned 'compliant' artifacts,
it would be actually useful to know where to find already existing
ones. so, has anyone taken on the maven repo / metadata plugin / etc
side? is there something available for reuse?
hopefully if we can provide a dead-easy procedure to package wicket
components *and* a place to store them (a maven repo -- how about
apache servers?) , then more and more components will become
'compliant' ... which means more and more will be eventually
discovered and registered.
still, i think it's fair to support non-compliant components as well.
if people use the app, those are very likely to be modified and kept
up-to-date.
francisco
On Tue, Dec 16, 2008 at 5:00 PM, Jonathan Locke
jonathan.lo...@gmail.com wrote:
you have a point. but while it's true it's not completely general, i'm
personally only interested in a library of components. and at present
components delivered by maven.
francisco treacy-2 wrote:
interesting post.
there's also
http://www.nabble.com/Open-wicket-component-collection-anywhere--td19450431.html
however sometimes 'automatic' doesn't work simply because people don't
mavenize their projects, it's just a bunch of files thrown in an svn
repo, or even a snippet of code. and you can't force them to use a
certain container, maven plugin, etc. imagine when it doesn't fit (a
snippet or an ide plugin).
depending on the projects' structure i'll take a look and try to find
the way to automatically pick up as much as possible.
i'm thinking of publishing wickethub's source code so it feels more of
a community project.
francisco
On Tue, Dec 16, 2008 at 10:08 AM, Maarten Bosteels
mbosteels@gmail.com wrote:
On Mon, Dec 15, 2008 at 10:43 PM, Jonathan Locke
jonathan.lo...@gmail.comwrote:
oh yeah, there's a post where we started figuring out some details about
how
this would work somewhere on this list
Here it is :
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
Maarten
Jonathan Locke wrote:
this is cool, although i still think this should be auto-updated
through
a
maven registry crawler. if everyone put the right meta information in
their wicket jars, this resource registry would be entirely automatic,
always fresh, running demos, etc...
francisco treacy-2 wrote:
i came up with an idea during the last weeks, having some trouble
finding wicket resources.
although we have wicketstuff (which is great, and even more now with
jeremy's awesome job of reorganizing it) i feel there are still lots
of components, plugins or tools that are lost in cyberspace. thought
it would be neat to keep a sort of
Re: Wicket stuff core, archetypes?
you're certainly free to go in whatever direction you want, but i still like the idea of a fully decentralized model. there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) i also think the nexus indexer is enough. you just need to find the artifact with nexus. parsing the metadata would be done after you download the artifact that you found. at that point you can do anything with it, including extracting URLs or even embedded images (might be a nice option for screenshots). putting jar metadata in META-INF is much more appropriate in my mind because it's not maven-specific. the idea of a wicket component is not a maven-centric idea and a maven repository is just one way to publish a component. there are certainly going to be others. i do think that it might be a good idea to make the component metadata a separate xml file in a subfolder of META-INF instead of putting that info directly in the existing jar properties file. this is a lot more extensible and would allow multiple components in a single jar and would also uniquely identify a wicket component and be quite searchable with nexus by just looking for: META-INF/wicket/components.xml // define components in this jar (relative reference to metadata files, in this case: // component1/metadata.xml and component2/metadata.xml) META-INF/wicket/component1/metadata.xml // define metadata for first component META-INF/wicket/component2/metadata.xml // metadata for second component META-INF/wicket/component2/screenshots/1.jpg// embedded screenshots for second component META-INF/wicket/component2/screenshots/2.jpg at least as i understand it... if not, maybe nexus needs to be extended... francisco treacy-2 wrote: i don't completely agree: - to be searched by nexus, repo needs to be nexus-aware: i.e. nexus-maven-repository-index.properties and nexus-maven-repository-index.zip files need to be deployed to the /.index folder at maven repository root. we are mainly talking about wicketstuff projects currently hosted in a non-indexed (nothing at http://wicketstuff.org/maven/repository/.index/) community-owned repo. as far as i know, there are no wicket components in maven central repo. i insist, so long as wicketstuff is *our repo* we can do whatever we want with it. we can decide *not to ban* wickethub's crawler (our crawler). we still can use nexus though, but we're not forced to do so - moreover, no specific metadata indexed: Nexus indexer component provides an API to index Maven repository, merge and download index updates. It also provides an API to search through registered indexes using various search criteria, including: * Browse through repository indexes * Search jars by artifactId and groupId * Search jars by the packaging type (e.g. to find Maven plugins or Archetypes) * Search jars by sha1 (e.g. to identify arbitrary jars with actual Maven artifacts) * Search Maven artifacts/jar by class name (e.g. resolve classpath issues from build errors or class not found exceptions) ...knowing that we need to index specific metadata (http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata). by the way, i wouldn't store metadata under META-INF inside the jar; i would rather include it in the pom file. let's put an example, let's say we need to display up-to-date url of screenshots (or examples or whatever) Screenshots=http://mycomponents.com/slider/screenshots/1.jpg,http://mycomponents.com/slider/screenshots/2.jpg,... wickethub will somehow need to know about those urls. how could it grab that out of nexus? i had a look at their lucene api and i'm not aware of the aforementioned scenario being possible. wickethub's crawler is a custom solution. it has to be smarter in that regard - to be able to keep synchronized custom data *we* (but not everybody) will be using in maven artifacts. francisco On Thu, Jan 15, 2009 at 5:37 PM, Jonathan Locke jonathan.lo...@gmail.com wrote: cool. this definitely looks like the right approach to me (assuming it indexes most of the big repos) jon Rodolfo Hansen wrote: Yes, you should use the nexus index for the repository http://nexus.sonatype.org/ The indexer api is pretty straight forward: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample you could search for artifacts with the appropriate metadata, or search inside the jars for some specific file / class (I think) On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy francisco.tre...@gmail.com wrote: wasn't this someone martijn? On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: For perusing the maven repository, one
Re: Wicket stuff core, archetypes?
you're certainly free to go in whatever direction you want, to be clear, i fully agree on the decentralized model for: - people and the development of this app, and data contributed by wicket users: this should be as democratic as possible - artifacts / components: there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) we should support any mavenized or non-mavenized artifacts, wherever those may live - you're right there (however i thought you said before you were interested at present only by components delivered by maven). parsing the metadata would be done after you download the artifact that you found. okay, fair enough. i have some doubts though: 1. in this scenario, downloading every artifact on earth just to open it and see if there's some wicket info inside is... impossible. 2. you just need to find the artifact with nexus. in your original blog post you say Basically, I'd like to see us crawl maven repos looking for JAR'ed Wicket components with a particular set of meta-data i don't see how nexus can help there. let's put another example: i create a mootools integration component, i mavenize it with package name com.mymootools.wicket and publish it in central repo. how does nexus help in finding that, if it doesn't know anything about META-INF/*.xml? ... *unless* you're planning people to submit their jar urls to wickethub. that would be a whole other story. but then again, nexus would be useless as we will already have the urls to components (no need to crawl or search - only to download the jar, open it up and update metadata in wickethub) for screenshots and the internal structure of the xml file, we shall see later, but i generally agree with you francisco parsing the metadata would be done after you download the artifact that you found. at that point you can do anything with it, including extracting URLs or even embedded images (might be a nice option for screenshots). putting jar metadata in META-INF is much more appropriate in my mind because it's not maven-specific. the idea of a wicket component is not a maven-centric idea and a maven repository is just one way to publish a component. there are certainly going to be others. i do think that it might be a good idea to make the component metadata a separate xml file in a subfolder of META-INF instead of putting that info directly in the existing jar properties file. this is a lot more extensible and would allow multiple components in a single jar and would also uniquely identify a wicket component and be quite searchable with nexus by just looking for: META-INF/wicket/components.xml // define components in this jar (relative reference to metadata files, in this case: // component1/metadata.xml and component2/metadata.xml) META-INF/wicket/component1/metadata.xml // define metadata for first component META-INF/wicket/component2/metadata.xml // metadata for second component META-INF/wicket/component2/screenshots/1.jpg// embedded screenshots for second component META-INF/wicket/component2/screenshots/2.jpg at least as i understand it... if not, maybe nexus needs to be extended... francisco treacy-2 wrote: i don't completely agree: - to be searched by nexus, repo needs to be nexus-aware: i.e. nexus-maven-repository-index.properties and nexus-maven-repository-index.zip files need to be deployed to the /.index folder at maven repository root. we are mainly talking about wicketstuff projects currently hosted in a non-indexed (nothing at http://wicketstuff.org/maven/repository/.index/) community-owned repo. as far as i know, there are no wicket components in maven central repo. i insist, so long as wicketstuff is *our repo* we can do whatever we want with it. we can decide *not to ban* wickethub's crawler (our crawler). we still can use nexus though, but we're not forced to do so - moreover, no specific metadata indexed: Nexus indexer component provides an API to index Maven repository, merge and download index updates. It also provides an API to search through registered indexes using various search criteria, including: * Browse through repository indexes * Search jars by artifactId and groupId * Search jars by the packaging type (e.g. to find Maven plugins or Archetypes) * Search jars by sha1 (e.g. to identify arbitrary jars with actual Maven artifacts) * Search Maven artifacts/jar by class name (e.g. resolve classpath issues from build errors or class not found exceptions) ...knowing that we need to index specific metadata (http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata). by the way, i wouldn't store metadata under META-INF inside the jar; i would rather include it in the
Re: Wicket stuff core, archetypes?
i think maven searching is an ideal way to publish and discover wicket components at present. i never meant to imply that that should be the only way to do this or that the idea of a wicket component jar should be tied to something like a repository or a transport. i also don't think it should be tied to a specific repo of discovered meta information like wicket hub. that creates a centralized architecture and as much as i like the idea of wicket hub a lot, it would be nice to enable other parties to build similar wicket component searching technologies that are not linked to wicket hub. for example, someone could gather wicket components for an IDE plugin, to store in some other type of repository than maven or to create an index for some future google search plugin. my simplistic understanding was that nexus could search for jars with certain files in them. all we need from nexus is the ability to get a list of jar artifacts which contain the file META-INF/wicket/components.xml because all such files will be wicket component jars (subject to downloading and parsing, of course). if nexus can't do that, i think that's a flaw in nexus and it ought to be extended so that it can do that. it would be worth talking to them about our needs to see if they could help us. i think that a nexus driven wicket component repository would be beneficial advertising for the nexus project, and it should not be too hard to achieve. jon francisco treacy-2 wrote: you're certainly free to go in whatever direction you want, to be clear, i fully agree on the decentralized model for: - people and the development of this app, and data contributed by wicket users: this should be as democratic as possible - artifacts / components: there may someday be wicket components in central or elsewhere, even outside maven repos (downloadable via HTTP like matej's inmethod stuff was for a while) we should support any mavenized or non-mavenized artifacts, wherever those may live - you're right there (however i thought you said before you were interested at present only by components delivered by maven). parsing the metadata would be done after you download the artifact that you found. okay, fair enough. i have some doubts though: 1. in this scenario, downloading every artifact on earth just to open it and see if there's some wicket info inside is... impossible. 2. you just need to find the artifact with nexus. in your original blog post you say Basically, I'd like to see us crawl maven repos looking for JAR'ed Wicket components with a particular set of meta-data i don't see how nexus can help there. let's put another example: i create a mootools integration component, i mavenize it with package name com.mymootools.wicket and publish it in central repo. how does nexus help in finding that, if it doesn't know anything about META-INF/*.xml? ... *unless* you're planning people to submit their jar urls to wickethub. that would be a whole other story. but then again, nexus would be useless as we will already have the urls to components (no need to crawl or search - only to download the jar, open it up and update metadata in wickethub) for screenshots and the internal structure of the xml file, we shall see later, but i generally agree with you francisco parsing the metadata would be done after you download the artifact that you found. at that point you can do anything with it, including extracting URLs or even embedded images (might be a nice option for screenshots). putting jar metadata in META-INF is much more appropriate in my mind because it's not maven-specific. the idea of a wicket component is not a maven-centric idea and a maven repository is just one way to publish a component. there are certainly going to be others. i do think that it might be a good idea to make the component metadata a separate xml file in a subfolder of META-INF instead of putting that info directly in the existing jar properties file. this is a lot more extensible and would allow multiple components in a single jar and would also uniquely identify a wicket component and be quite searchable with nexus by just looking for: META-INF/wicket/components.xml // define components in this jar (relative reference to metadata files, in this case: // component1/metadata.xml and component2/metadata.xml) META-INF/wicket/component1/metadata.xml // define metadata for first component META-INF/wicket/component2/metadata.xml // metadata for second component META-INF/wicket/component2/screenshots/1.jpg// embedded screenshots for second component META-INF/wicket/component2/screenshots/2.jpg at least as i understand it... if not, maybe nexus needs to be extended... francisco treacy-2 wrote: i don't completely agree: - to be searched
Re: Things I miss in Wicket
On Fri, Jan 16, 2009 at 01:47:16PM +0100, Tobias Marx exclaimed: I think there already a lot of projects out there that try to optimize web-development in Java. Instead of starting yet another project I think it would be better to find out which framework is most flexible and has the best design architecture and philosophy and support this project. So far I have looked at Tapestry5 and Wicket. What I don't like about Tapestry is, that it is currently not possible to write web applications that allow you to create webapplications, meaning that you can not read the configuration of a form from the database and create all kinds of components dynamically. For example I wanted to implement an Admin page in which you can define custom fields (for a configurable community website)...but this is not what Tapestry5 was designed for. What I don't like about Wicket is, that it is like writing normal Java applications - although rich clients applications are being replaced with web-based solutions and there is a fundamental difference between web-applications and normal java applications. If you have a java application as a product, it is normal to employ software developers that work on bug fixes and new features all the time - they constantly develop and it is expensiveeverything has to be done by a software developer. I think this is why most of us love wicket... It *is* like writing a normal java application and, IMO, comes out more maintainable and reliable in the end. An ideal web-application is developed once and the Java code is never touched again for 3-5 years until there are a lot of new features necessary but in this time there could be several small changes or complete re-designs...and in that time this should be a pure matter of HTMLing without the need of touching the Java code. If a new input field is added or some new strings.or whateveror maybe a new Flash component etcthis should still work without changing the -war file that carries the Java code...only changes in the templates or the database should be made. This sounds like you want a CMS? Wicket does does not really allow this. Or assume you have a web-application you want to sell - and don't want the customer to know Javathey would be really restricted in the changes that are possible. Another advantage of Wicket is that it creates a session for every visitor - no matter whether it is a crawler/search engine that does not need a session or a logged in user If there was a coding competition to write a web-application with as few lines of code as possibleI think Tapestry5 would win over Wicket. But with some changes in Wicket and some aspects of Tapestry5, this would be a lot better. What about merging Wicket and Tapestry? Similiar to Wicket with Tapestry templates? So far most of my projects are still good old PHP codestupid but efficient. It loads fast when you use file or memory based caching, you can always resolve any kind of bug within minutes and you never end up debugging for 5 days until you find out that it is not possible without any fundamental changes in the core of some Java framework you do not wish to know in detail.. So long... I can see where your coming from, but I think your missing the point. I've written several large web applications using PHP, JSP+Servlet, Spring MVC, etc. Large applications, especially with a large development team, tend to become spaghetti very quickly. Using wicket allows us to seperate responsibilities (HTML designers, jr programmers, sr programmers, etc) very cleanly. The end result is a more maintainable and reliable product. Not to mention that the components you create can be used on future projects. This saves a ton of time. In my experience, going in later and adding new features is much easier because the code is cleaner and the design is better (this is one definition of maintainability). It sounds like you want something with a lot of *magic* like grails. To be honest I used grails for about 2-3 months and I just couldn't get into it. All the behind the scenes vodoo seemed to get in the way, I prefer to know how all the pieces are working. If your building small to medium size applications I could see grails or a CMS fitting your needs. You didn't mention how much you have done with wicket, but I think it takes a while (and a project or two) before you really realize the beauty of its approach to building web applications. I certainly won't be switching away any time soon :-) -Ryan Toby Original-Nachricht Datum: Thu, 15 Jan 2009 21:46:08 -0500 Von: Trevor Burnham trevorburn...@gmail.com An: Tobias Marx superoverdr...@gmx.de Betreff: Re: Things I miss in Wicket Hi Toby, I've been considering creating a new project that would split away from Wicket, refine it and streamline it for similar reasons, particularly to reduce the number of lines of code that are needed
Wizard Exception
I am testing the concurrency of my application now. I found out when more than one user visit the same wizard page, it will have the exception. The exception happened, when second user push next button on the wizard page. The method Form.onFormSubmitted will be called twice, the first will have the exception as following: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = form]] threw an exception org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component [MarkupContainer [Component id = form]] threw an exception at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:194) at org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:91) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1175) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1252) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1353) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:355) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:200) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:183) ... 22 more Caused by: java.lang.IllegalStateException: ServletRequest does not contain multipart content at org.apache.wicket.protocol.http.servlet.MultipartServletWebRequest.init(MultipartServletWebRequest.java:90) at org.apache.wicket.protocol.http.servlet.ServletWebRequest.newMultipartWebRequest(ServletWebRequest.java:446) at org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1476) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:774) ... 27 more Is it the bug from my application or from Wicket? If it is bug from my application, how can I fix it? -- View this message in context: http://www.nabble.com/Wizard-Exception-tp21524282p21524282.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
