You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thies Edeling <th...@rrm.net> on 2007/11/07 01:03:44 UTC
eHour migrated to Wicket
Hello all,
I've finally migrated my time tracking tool, eHour, from Struts to Wicket !
eHour is a webbased time tracking tool for consultancy companies and
other project based businesses.
The primary objective is to keep time tracking as simple and user
friendly as possible while still being
very effective at measuring and reporting the amount of time your team
spends on a project.
More details at http://www.ehour.nl/
I have to say that I underestimated the amount of time needed to do the
whole migration, mostly due to the amount
of JSP/JSTL/Struts code I had to migrate and the learning
curve/documentation of Wicket. But I'm still very happy I
did the migration. Development is fun again and Wicket feels a lot more
robust than a JSP/JSTL/Ajax/Struts combo.
Thanks to the Wicket team for this excellent framework !
regards
Thies
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: eHour migrated to Wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> I've finally migrated my time tracking tool, eHour, from Struts to Wicket !
>
> eHour is a webbased time tracking tool for consultancy companies and
> other project based businesses.
> The primary objective is to keep time tracking as simple and user
> friendly as possible while still being
> very effective at measuring and reporting the amount of time your team
> spends on a project.
> More details at http://www.ehour.nl/
Congrats! Looks good.
> I have to say that I underestimated the amount of time needed to do the
> whole migration, mostly due to the amount
> of JSP/JSTL/Struts code I had to migrate and the learning
> curve/documentation of Wicket. But I'm still very happy I
> did the migration. Development is fun again and Wicket feels a lot more
> robust than a JSP/JSTL/Ajax/Struts combo.
> Thanks to the Wicket team for this excellent framework !
And you, thanks for being part of the community!
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: eHour migrated to Wicket
Posted by Nick Heudecker <nh...@gmail.com>.
Good looking app. What kinds of lessons did you learn in the migration? It
would be interesting to collect them into a wiki page.
--
Nick Heudecker
Professional Wicket Training & Consulting
http://www.systemmobile.com
Eventful - Intelligent Event Management
http://www.eventfulhq.com
RE: Rendering a fieldset class attribute
Posted by William Hoover <wh...@nemours.org>.
I hear you... read the docs... "addAttributeIfNotPresent" :)
It seems odd that the AttributeModifier is under the org.apache.wicket package, but the SimpleAttributeModifier is under the org.apache.wicket.behavior package? They both extend AbstractBehavior.
I would have to agree with you... it does seem too broad. One of the aspects of Wicket that makes it enjoyable to program in is that they have kept its usage very simple!
-----Original Message-----
From: Al Maw [mailto:wicket@almaw.com]
Sent: Wednesday, November 07, 2007 8:10 PM
To: users@wicket.apache.org
Subject: Re: Rendering a fieldset class attribute
William Hoover wrote:
> Is it better to use AbstractBehavior and override onComponentTag?
>
> I assume that the AttributeModifier is only for cases when the attribute already exists in the markup, correct?
Well, given the javadoc I told you to read for the second parameter
there, no. ;-)
It doesn't make much difference which you use.
AbstractBehavior is more direct and concise.
AttributeModifier is named such that people will find it.
I tend to use the former for what you're doing, and the latter if I
already have a model kicking around.
There's also a SimpleAttributeModifier if you have a simple String, and
an AttributeAppender if you wish to mess with what's currently there.
IMO, the API here is far too broad - we should just give people
AbstractBehavior and tell them to get on with it, but hey ho.
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering a fieldset class attribute
Posted by Al Maw <wi...@almaw.com>.
William Hoover wrote:
> Is it better to use AbstractBehavior and override onComponentTag?
>
> I assume that the AttributeModifier is only for cases when the attribute already exists in the markup, correct?
Well, given the javadoc I told you to read for the second parameter
there, no. ;-)
It doesn't make much difference which you use.
AbstractBehavior is more direct and concise.
AttributeModifier is named such that people will find it.
I tend to use the former for what you're doing, and the latter if I
already have a model kicking around.
There's also a SimpleAttributeModifier if you have a simple String, and
an AttributeAppender if you wish to mess with what's currently there.
IMO, the API here is far too broad - we should just give people
AbstractBehavior and tell them to get on with it, but hey ho.
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Rendering a fieldset class attribute
Posted by William Hoover <wh...@nemours.org>.
Is it better to use AbstractBehavior and override onComponentTag?
I assume that the AttributeModifier is only for cases when the attribute already exists in the markup, correct?
-----Original Message-----
From: Al Maw [mailto:wicket@almaw.com]
Sent: Wednesday, November 07, 2007 7:48 PM
To: users@wicket.apache.org
Subject: Re: Rendering a fieldset class attribute
William Hoover wrote:
>
> final AttributeModifier levelModifier = new AttributeModifier("class",
> new Model() {
> @Override
> public Object getObject() {
> return "fieldset-class";
> }
> });
[...]
> The fieldset is not rendering the css class attribute?
This is because you need to provide a second constructor parameter of
true (read the javadoc for AttributeModifier).
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Rendering a fieldset class attribute
Posted by Al Maw <wi...@almaw.com>.
William Hoover wrote:
>
> final AttributeModifier levelModifier = new AttributeModifier("class",
> new Model() {
> @Override
> public Object getObject() {
> return "fieldset-class";
> }
> });
[...]
> The fieldset is not rendering the css class attribute?
This is because you need to provide a second constructor parameter of
true (read the javadoc for AttributeModifier).
Regards,
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Rendering a fieldset class attribute
Posted by William Hoover <wh...@nemours.org>.
never mind... my mistake i needed to use AbstractBehavior (below). Sorry for the post :)
fieldset.add(new AbstractBehavior() {
@Override
public void onComponentTag(Component component, ComponentTag tag) {
tag.put("class", "fieldset-class");
}
});
-----Original Message-----
From: William Hoover [mailto:whoover@nemours.org]
Sent: Wednesday, November 07, 2007 6:26 PM
To: users@wicket.apache.org
Subject: Rendering a fieldset class attribute
Is it appropriate to have the following...
final WebMarkupContainerWithAssociatedMarkup fieldset = new WebMarkupContainerWithAssociatedMarkup(
"fieldset");
final AttributeModifier levelModifier = new AttributeModifier("class",
new Model() {
@Override
public Object getObject() {
return "fieldset-class";
}
});
fieldset.add(levelModifier);
add(fieldset);
with...
<fieldset wicket:id="fieldset">
...
</fieldset>
The fieldset is not rendering the css class attribute?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Rendering a fieldset class attribute
Posted by William Hoover <wh...@nemours.org>.
Is it appropriate to have the following...
final WebMarkupContainerWithAssociatedMarkup fieldset = new WebMarkupContainerWithAssociatedMarkup(
"fieldset");
final AttributeModifier levelModifier = new AttributeModifier("class",
new Model() {
@Override
public Object getObject() {
return "fieldset-class";
}
});
fieldset.add(levelModifier);
add(fieldset);
with...
<fieldset wicket:id="fieldset">
...
</fieldset>
The fieldset is not rendering the css class attribute?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org