You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ricardo Mayerhofer <ri...@gmail.com> on 2008/11/26 19:51:59 UTC
Wicket and CoC
I started to use wicket some time ago, and I'm really enjoying it. Best
framework ever.
But I've some suggestions.
I think wicket could be better if it had less boiler plate code. This could
be reduced by using CoC.
Take the FeedBackPanel for example, you always have to add the component on
the web page, even if no special handling is requires (which is almost the
case).
Wicket could have some reserved ids, so if I add a markup with id
feedbackPanel, a feedbackpanel component is automatically added to that
page.
Another example is SubmitLink component. No special handling required, but
for wicket sake the developer must add it on the java the page.
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
Very nice indeed. Based on your example I build my own:
public class ConventionalComponentResolver implements IComponentResolver {
public boolean resolve(MarkupContainer markupContainer, MarkupStream
markupStream, ComponentTag componentTag) {
CharSequence wicketId = componentTag.getString("wicket:id");
if ( "submitLink".equals(wicketId) ) {
markupContainer.autoAdd(new SubmitLink( "submitLink" ),
markupStream);
return true;
}
....
Nino.Martinez wrote:
>
> COOL!!! :)
>
> Jeremy Thomerson wrote:
>> You can do exactly what you asked in less than 40 lines of code - and not
>> be
>> bound to the class name in the HTML (which you shouldn't do). Here's
>> how:
>>
>> IN YOUR APPLICATION CLASS:
>>
>> @Override
>> protected void init() {
>> super.init();
>> registerConventionalComponent("feedbackPanel",
>> FeedbackPanel.class);
>> registerConventionalComponent("submitLink", SubmitLink.class);
>> registerConventionalComponent("submitButton", Button.class);
>> }
>> private void registerConventionalComponent(String id, Class<? extends
>> Component> clazz) {
>> getPageSettings().addComponentResolver(new
>> ConventionalComponentResolver(id, clazz));
>> }
>> private static final class ConventionalComponentResolver implements
>> IComponentResolver {
>> private static final long serialVersionUID = 1L;
>> private final String mID;
>> private final Class<? extends Component> mComponentClass;
>>
>> public ConventionalComponentResolver(String id, Class<? extends
>> Component> clazz) {
>> mID = id;
>> mComponentClass = clazz;
>> }
>> public boolean resolve(MarkupContainer container, MarkupStream
>> markupStream, ComponentTag tag) {
>> CharSequence wicketId = tag.getString("wicket:id");
>> if (mID.equals(wicketId)) {
>> container.autoAdd(createInstance(), markupStream);
>> // Yes, we handled the tag
>> return true;
>> }
>> // We were not able to handle the tag
>> return false;
>> }
>> private Component createInstance() {
>> try {
>> return
>> mComponentClass.getConstructor(String.class).newInstance(mID);
>> } catch (Exception ex) {
>> throw new WicketRuntimeException("Error creating
>> component
>> instance of class: " + mComponentClass.getName(), ex);
>> }
>> }
>> }
>> NIFTY!! I hadn't written any IComponentResolver's before - but wanted to
>> try it. Wicket is AWESOME!! It makes it so easy to customize the
>> framework
>> to YOUR needs without imposing one person's ideas on another person.
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20975432.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
COOL!!! :)
Jeremy Thomerson wrote:
> You can do exactly what you asked in less than 40 lines of code - and not be
> bound to the class name in the HTML (which you shouldn't do). Here's how:
>
> IN YOUR APPLICATION CLASS:
>
> @Override
> protected void init() {
> super.init();
> registerConventionalComponent("feedbackPanel", FeedbackPanel.class);
> registerConventionalComponent("submitLink", SubmitLink.class);
> registerConventionalComponent("submitButton", Button.class);
> }
> private void registerConventionalComponent(String id, Class<? extends
> Component> clazz) {
> getPageSettings().addComponentResolver(new
> ConventionalComponentResolver(id, clazz));
> }
> private static final class ConventionalComponentResolver implements
> IComponentResolver {
> private static final long serialVersionUID = 1L;
> private final String mID;
> private final Class<? extends Component> mComponentClass;
>
> public ConventionalComponentResolver(String id, Class<? extends
> Component> clazz) {
> mID = id;
> mComponentClass = clazz;
> }
> public boolean resolve(MarkupContainer container, MarkupStream
> markupStream, ComponentTag tag) {
> CharSequence wicketId = tag.getString("wicket:id");
> if (mID.equals(wicketId)) {
> container.autoAdd(createInstance(), markupStream);
> // Yes, we handled the tag
> return true;
> }
> // We were not able to handle the tag
> return false;
> }
> private Component createInstance() {
> try {
> return
> mComponentClass.getConstructor(String.class).newInstance(mID);
> } catch (Exception ex) {
> throw new WicketRuntimeException("Error creating component
> instance of class: " + mComponentClass.getName(), ex);
> }
> }
> }
> NIFTY!! I hadn't written any IComponentResolver's before - but wanted to
> try it. Wicket is AWESOME!! It makes it so easy to customize the framework
> to YOUR needs without imposing one person's ideas on another person.
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Jeremy Thomerson <je...@wickettraining.com>.
You can do exactly what you asked in less than 40 lines of code - and not be
bound to the class name in the HTML (which you shouldn't do). Here's how:
IN YOUR APPLICATION CLASS:
@Override
protected void init() {
super.init();
registerConventionalComponent("feedbackPanel", FeedbackPanel.class);
registerConventionalComponent("submitLink", SubmitLink.class);
registerConventionalComponent("submitButton", Button.class);
}
private void registerConventionalComponent(String id, Class<? extends
Component> clazz) {
getPageSettings().addComponentResolver(new
ConventionalComponentResolver(id, clazz));
}
private static final class ConventionalComponentResolver implements
IComponentResolver {
private static final long serialVersionUID = 1L;
private final String mID;
private final Class<? extends Component> mComponentClass;
public ConventionalComponentResolver(String id, Class<? extends
Component> clazz) {
mID = id;
mComponentClass = clazz;
}
public boolean resolve(MarkupContainer container, MarkupStream
markupStream, ComponentTag tag) {
CharSequence wicketId = tag.getString("wicket:id");
if (mID.equals(wicketId)) {
container.autoAdd(createInstance(), markupStream);
// Yes, we handled the tag
return true;
}
// We were not able to handle the tag
return false;
}
private Component createInstance() {
try {
return
mComponentClass.getConstructor(String.class).newInstance(mID);
} catch (Exception ex) {
throw new WicketRuntimeException("Error creating component
instance of class: " + mComponentClass.getName(), ex);
}
}
}
NIFTY!! I hadn't written any IComponentResolver's before - but wanted to
try it. Wicket is AWESOME!! It makes it so easy to customize the framework
to YOUR needs without imposing one person's ideas on another person.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Nov 27, 2008 at 2:05 AM, Alex Objelean
<al...@isdc.ro>wrote:
>
> Using AutoComponentResolver, you can add a feedback panel like this:
> <wicket:component
> class="org.apache.wicket.markup.html.panel.FeedbackPanel"/>
>
>
>
>
> Ricardo Mayerhofer wrote:
> >
> > I started to use wicket some time ago, and I'm really enjoying it. Best
> > framework ever.
> > But I've some suggestions.
> > I think wicket could be better if it had less boiler plate code. This
> > could be reduced by using CoC.
> > Take the FeedBackPanel for example, you always have to add the component
> > on the web page, even if no special handling is requires (which is almost
> > the case).
> > Wicket could have some reserved ids, so if I add a markup with id
> > feedbackPanel, a feedbackpanel component is automatically added to that
> > page.
> > Another example is SubmitLink component. No special handling required,
> but
> > for wicket sake the developer must add it on the java the page.
> >
>
> --
> View this message in context:
> http://www.nabble.com/Wicket-and-CoC-tp20706881p20714917.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket and CoC
Posted by Alex Objelean <al...@isdc.ro>.
Using AutoComponentResolver, you can add a feedback panel like this:
<wicket:component
class="org.apache.wicket.markup.html.panel.FeedbackPanel"/>
Ricardo Mayerhofer wrote:
>
> I started to use wicket some time ago, and I'm really enjoying it. Best
> framework ever.
> But I've some suggestions.
> I think wicket could be better if it had less boiler plate code. This
> could be reduced by using CoC.
> Take the FeedBackPanel for example, you always have to add the component
> on the web page, even if no special handling is requires (which is almost
> the case).
> Wicket could have some reserved ids, so if I add a markup with id
> feedbackPanel, a feedbackpanel component is automatically added to that
> page.
> Another example is SubmitLink component. No special handling required, but
> for wicket sake the developer must add it on the java the page.
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20714917.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
I think if you decide to rewrite an existing application with wicket, the
names will be your least problem
(http://chadfowler.com/2006/12/27/the-big-rewrite). Even though you can use
the configuration part of CoC...
igor.vaynberg wrote:
>
> right, so i should rename concepts from code that was written before
> wicket just because we are using wicket now...
>
> -igor
>
> On Wed, Nov 26, 2008 at 3:32 PM, Ricardo Mayerhofer
> <ri...@gmail.com> wrote:
>>
>> Hi Igor,
>> "User feedback" is different from "Feedback Panel", and I think is this
>> difference is good, otherwise you will use one word with two meanings
>> under
>> the same project (I think I just defined ambiguity :)).
>>
>> Think about a project that uses a API that has a name for a concept and
>> the
>> application has the same name for another concept:
>>
>> String getB() {
>> return externalApi.getA(...);
>> }
>>
>> String getA() {
>> return externalApi.getB(...);
>> }
>>
>>
>> or
>>
>> add( new FeedBackPanel( "userFormResponse" ) )
>> add( new TextArea( "feedBackPanel" ) )
>>
>> I've seen the first in a project, it confuses people.
>>
>> And of course. frameworks doesn't dictateds application domain, because
>> technical things and domain things are different. Your user will never
>> ask,
>> "hey creates a send to server clickable here for me" (user name for
>> submit
>> link).
>>
>> CoC doesn't mean Convention Only or Convention Instead Configuration. Its
>> purpose is to speed up development in most cases and keep the same
>> effort,
>> as if it was not there, on the other cases. If someone wants to extend
>> submit link, no problem just do it and add it on the java page.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
>>> <ri...@gmail.com> wrote:
>>>>
>>>> Perhaps the name could be userFeedBackPanel :)
>>>> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>>>
>>> why should conventions of a framework we use dictate our names in the
>>> application domain? within our application "user feedback" is a well
>>> known term. so just because we are using wicket we should change it?
>>> this is why stuff like that doesnt go into core :)
>>>
>>>> I'm just talking about code duplication, add( new SubmitLink(
>>>> "submitLink" )
>>>> ) and similars many times in a code doenst makes a programmer happier.
>>>> OOP (object oriented programming) isn't always the best tools to solve
>>>> code
>>>> duplication. So sometimes AOP (aspect oriented programming) comes to
>>>> mind,
>>>> other times CoC (convention over configuration). (I hope Martijn is
>>>> happy
>>>> by
>>>> the acronyms explanations :)).
>>>>
>>>> I'm not saying that it should be in wicket core (as you guys keep it
>>>> thin
>>>> as
>>>> you can) and I'm glad wicket core makes me able to extend it, in a way
>>>> I
>>>> can
>>>> implement this (thats a huge plus)
>>>
>>> this kind of stuff adds ambiguity - that is mostly why it doesnt make
>>> it into core. you say "submitLink" creates a component, fine, but in
>>> our app we have our own subclass of SubmitLink we use that includes
>>> our css styles, indicators, etc - which again breaks with your
>>> suggestion.
>>>
>>>> I'm just saying that this is not a bad idea, mainly when you care about
>>>> saving programming efforts and clean code.
>>>
>>> you are saving a few lines of code by adding a lot of ambiguity. imho,
>>> the trade off is not worth it. but we still make it possible for you
>>> to shoot yourself in the foot if you choose to do so :)
>>>
>>> -igor
>>>
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>>>
>>>>> in our app components with id feedbackPanel are often used to present
>>>>> a user with a user-feedback panel they can use to submit
>>>>> suggestions...
>>>>>
>>>>> -igor
>>>>>
>>>>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>>>>> <ri...@gmail.com> wrote:
>>>>>>
>>>>>> Hi Martijin,
>>>>>> First of all thank you for your response.
>>>>>> I guess automation != magic. Automation means that computers or
>>>>>> frameworks
>>>>>> helps humans accomplishing repetitive tasks, so developers can better
>>>>>> focus
>>>>>> on the problem being solved, rather than having to copy and paste
>>>>>> same
>>>>>> code
>>>>>> over and over (boilerplate).
>>>>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>>>>> combo
>>>>>> box? Or he have to tell it again, in a different way? IMO it's better
>>>>>> to
>>>>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>>>>
>>>>>>
>>>>>> Martijn Dashorst wrote:
>>>>>>>
>>>>>>> -1000,000,000,000
>>>>>>>
>>>>>>> First please don't assume someone understands your acronym du jour.
>>>>>>> I
>>>>>>> had to think really hard to understand that CoC means convention
>>>>>>> over
>>>>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>>>>
>>>>>>> Second this is not a task for wicket. You can think up any
>>>>>>> CoCamania
>>>>>>> you want in your own addon framework and publish it on 'stuff or
>>>>>>> google code, but I won't be using it ever nor including it in core.
>>>>>>>
>>>>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>>>>> don't need nor want to have to wave a dead chicken in front of my
>>>>>>> monitor and spend the bigger part of the day wondering which
>>>>>>> incantation I did wrong.
>>>>>>>
>>>>>>> Martijn
>>>>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>>>>> Best
>>>>>>>> framework ever.
>>>>>>>> But I've some suggestions.
>>>>>>>> I think wicket could be better if it had less boiler plate code.
>>>>>>>> This
>>>>>>>> could
>>>>>>>> be reduced by using CoC.
>>>>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>>>>> component
>>>>>>>> on
>>>>>>>> the web page, even if no special handling is requires (which is
>>>>>>>> almost
>>>>>>>> the
>>>>>>>> case).
>>>>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>>>>> that
>>>>>>>> page.
>>>>>>>> Another example is SubmitLink component. No special handling
>>>>>>>> required,
>>>>>>>> but
>>>>>>>> for wicket sake the developer must add it on the java the page.
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Become a Wicket expert, learn from the best:
>>>>>>> http://wicketinaction.com
>>>>>>> Apache Wicket 1.3.4 is released
>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20711124.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20711626.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Igor Vaynberg <ig...@gmail.com>.
right, so i should rename concepts from code that was written before
wicket just because we are using wicket now...
-igor
On Wed, Nov 26, 2008 at 3:32 PM, Ricardo Mayerhofer
<ri...@gmail.com> wrote:
>
> Hi Igor,
> "User feedback" is different from "Feedback Panel", and I think is this
> difference is good, otherwise you will use one word with two meanings under
> the same project (I think I just defined ambiguity :)).
>
> Think about a project that uses a API that has a name for a concept and the
> application has the same name for another concept:
>
> String getB() {
> return externalApi.getA(...);
> }
>
> String getA() {
> return externalApi.getB(...);
> }
>
>
> or
>
> add( new FeedBackPanel( "userFormResponse" ) )
> add( new TextArea( "feedBackPanel" ) )
>
> I've seen the first in a project, it confuses people.
>
> And of course. frameworks doesn't dictateds application domain, because
> technical things and domain things are different. Your user will never ask,
> "hey creates a send to server clickable here for me" (user name for submit
> link).
>
> CoC doesn't mean Convention Only or Convention Instead Configuration. Its
> purpose is to speed up development in most cases and keep the same effort,
> as if it was not there, on the other cases. If someone wants to extend
> submit link, no problem just do it and add it on the java page.
>
>
> igor.vaynberg wrote:
>>
>> On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
>> <ri...@gmail.com> wrote:
>>>
>>> Perhaps the name could be userFeedBackPanel :)
>>> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>>
>> why should conventions of a framework we use dictate our names in the
>> application domain? within our application "user feedback" is a well
>> known term. so just because we are using wicket we should change it?
>> this is why stuff like that doesnt go into core :)
>>
>>> I'm just talking about code duplication, add( new SubmitLink(
>>> "submitLink" )
>>> ) and similars many times in a code doenst makes a programmer happier.
>>> OOP (object oriented programming) isn't always the best tools to solve
>>> code
>>> duplication. So sometimes AOP (aspect oriented programming) comes to
>>> mind,
>>> other times CoC (convention over configuration). (I hope Martijn is happy
>>> by
>>> the acronyms explanations :)).
>>>
>>> I'm not saying that it should be in wicket core (as you guys keep it thin
>>> as
>>> you can) and I'm glad wicket core makes me able to extend it, in a way I
>>> can
>>> implement this (thats a huge plus)
>>
>> this kind of stuff adds ambiguity - that is mostly why it doesnt make
>> it into core. you say "submitLink" creates a component, fine, but in
>> our app we have our own subclass of SubmitLink we use that includes
>> our css styles, indicators, etc - which again breaks with your
>> suggestion.
>>
>>> I'm just saying that this is not a bad idea, mainly when you care about
>>> saving programming efforts and clean code.
>>
>> you are saving a few lines of code by adding a lot of ambiguity. imho,
>> the trade off is not worth it. but we still make it possible for you
>> to shoot yourself in the foot if you choose to do so :)
>>
>> -igor
>>
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> in our app components with id feedbackPanel are often used to present
>>>> a user with a user-feedback panel they can use to submit
>>>> suggestions...
>>>>
>>>> -igor
>>>>
>>>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>>>> <ri...@gmail.com> wrote:
>>>>>
>>>>> Hi Martijin,
>>>>> First of all thank you for your response.
>>>>> I guess automation != magic. Automation means that computers or
>>>>> frameworks
>>>>> helps humans accomplishing repetitive tasks, so developers can better
>>>>> focus
>>>>> on the problem being solved, rather than having to copy and paste same
>>>>> code
>>>>> over and over (boilerplate).
>>>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>>>> combo
>>>>> box? Or he have to tell it again, in a different way? IMO it's better
>>>>> to
>>>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>>>
>>>>>
>>>>> Martijn Dashorst wrote:
>>>>>>
>>>>>> -1000,000,000,000
>>>>>>
>>>>>> First please don't assume someone understands your acronym du jour. I
>>>>>> had to think really hard to understand that CoC means convention over
>>>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>>>
>>>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>>>> you want in your own addon framework and publish it on 'stuff or
>>>>>> google code, but I won't be using it ever nor including it in core.
>>>>>>
>>>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>>>> don't need nor want to have to wave a dead chicken in front of my
>>>>>> monitor and spend the bigger part of the day wondering which
>>>>>> incantation I did wrong.
>>>>>>
>>>>>> Martijn
>>>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>>>
>>>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>>>> Best
>>>>>>> framework ever.
>>>>>>> But I've some suggestions.
>>>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>>>> could
>>>>>>> be reduced by using CoC.
>>>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>>>> component
>>>>>>> on
>>>>>>> the web page, even if no special handling is requires (which is
>>>>>>> almost
>>>>>>> the
>>>>>>> case).
>>>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>>>> that
>>>>>>> page.
>>>>>>> Another example is SubmitLink component. No special handling
>>>>>>> required,
>>>>>>> but
>>>>>>> for wicket sake the developer must add it on the java the page.
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>>> Apache Wicket 1.3.4 is released
>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20711124.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
Hi Igor,
"User feedback" is different from "Feedback Panel", and I think is this
difference is good, otherwise you will use one word with two meanings under
the same project (I think I just defined ambiguity :)).
Think about a project that uses a API that has a name for a concept and the
application has the same name for another concept:
String getB() {
return externalApi.getA(...);
}
String getA() {
return externalApi.getB(...);
}
or
add( new FeedBackPanel( "userFormResponse" ) )
add( new TextArea( "feedBackPanel" ) )
I've seen the first in a project, it confuses people.
And of course. frameworks doesn't dictateds application domain, because
technical things and domain things are different. Your user will never ask,
"hey creates a send to server clickable here for me" (user name for submit
link).
CoC doesn't mean Convention Only or Convention Instead Configuration. Its
purpose is to speed up development in most cases and keep the same effort,
as if it was not there, on the other cases. If someone wants to extend
submit link, no problem just do it and add it on the java page.
igor.vaynberg wrote:
>
> On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
> <ri...@gmail.com> wrote:
>>
>> Perhaps the name could be userFeedBackPanel :)
>> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>
> why should conventions of a framework we use dictate our names in the
> application domain? within our application "user feedback" is a well
> known term. so just because we are using wicket we should change it?
> this is why stuff like that doesnt go into core :)
>
>> I'm just talking about code duplication, add( new SubmitLink(
>> "submitLink" )
>> ) and similars many times in a code doenst makes a programmer happier.
>> OOP (object oriented programming) isn't always the best tools to solve
>> code
>> duplication. So sometimes AOP (aspect oriented programming) comes to
>> mind,
>> other times CoC (convention over configuration). (I hope Martijn is happy
>> by
>> the acronyms explanations :)).
>>
>> I'm not saying that it should be in wicket core (as you guys keep it thin
>> as
>> you can) and I'm glad wicket core makes me able to extend it, in a way I
>> can
>> implement this (thats a huge plus)
>
> this kind of stuff adds ambiguity - that is mostly why it doesnt make
> it into core. you say "submitLink" creates a component, fine, but in
> our app we have our own subclass of SubmitLink we use that includes
> our css styles, indicators, etc - which again breaks with your
> suggestion.
>
>> I'm just saying that this is not a bad idea, mainly when you care about
>> saving programming efforts and clean code.
>
> you are saving a few lines of code by adding a lot of ambiguity. imho,
> the trade off is not worth it. but we still make it possible for you
> to shoot yourself in the foot if you choose to do so :)
>
> -igor
>
>>
>>
>> igor.vaynberg wrote:
>>>
>>> in our app components with id feedbackPanel are often used to present
>>> a user with a user-feedback panel they can use to submit
>>> suggestions...
>>>
>>> -igor
>>>
>>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>>> <ri...@gmail.com> wrote:
>>>>
>>>> Hi Martijin,
>>>> First of all thank you for your response.
>>>> I guess automation != magic. Automation means that computers or
>>>> frameworks
>>>> helps humans accomplishing repetitive tasks, so developers can better
>>>> focus
>>>> on the problem being solved, rather than having to copy and paste same
>>>> code
>>>> over and over (boilerplate).
>>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>>> combo
>>>> box? Or he have to tell it again, in a different way? IMO it's better
>>>> to
>>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>>
>>>>
>>>> Martijn Dashorst wrote:
>>>>>
>>>>> -1000,000,000,000
>>>>>
>>>>> First please don't assume someone understands your acronym du jour. I
>>>>> had to think really hard to understand that CoC means convention over
>>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>>
>>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>>> you want in your own addon framework and publish it on 'stuff or
>>>>> google code, but I won't be using it ever nor including it in core.
>>>>>
>>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>>> don't need nor want to have to wave a dead chicken in front of my
>>>>> monitor and spend the bigger part of the day wondering which
>>>>> incantation I did wrong.
>>>>>
>>>>> Martijn
>>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>>
>>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>>> Best
>>>>>> framework ever.
>>>>>> But I've some suggestions.
>>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>>> could
>>>>>> be reduced by using CoC.
>>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>>> component
>>>>>> on
>>>>>> the web page, even if no special handling is requires (which is
>>>>>> almost
>>>>>> the
>>>>>> case).
>>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>>> that
>>>>>> page.
>>>>>> Another example is SubmitLink component. No special handling
>>>>>> required,
>>>>>> but
>>>>>> for wicket sake the developer must add it on the java the page.
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>> Apache Wicket 1.3.4 is released
>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20711124.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Nov 26, 2008 at 1:57 PM, Ricardo Mayerhofer
<ri...@gmail.com> wrote:
>
> Perhaps the name could be userFeedBackPanel :)
> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
why should conventions of a framework we use dictate our names in the
application domain? within our application "user feedback" is a well
known term. so just because we are using wicket we should change it?
this is why stuff like that doesnt go into core :)
> I'm just talking about code duplication, add( new SubmitLink( "submitLink" )
> ) and similars many times in a code doenst makes a programmer happier.
> OOP (object oriented programming) isn't always the best tools to solve code
> duplication. So sometimes AOP (aspect oriented programming) comes to mind,
> other times CoC (convention over configuration). (I hope Martijn is happy by
> the acronyms explanations :)).
>
> I'm not saying that it should be in wicket core (as you guys keep it thin as
> you can) and I'm glad wicket core makes me able to extend it, in a way I can
> implement this (thats a huge plus)
this kind of stuff adds ambiguity - that is mostly why it doesnt make
it into core. you say "submitLink" creates a component, fine, but in
our app we have our own subclass of SubmitLink we use that includes
our css styles, indicators, etc - which again breaks with your
suggestion.
> I'm just saying that this is not a bad idea, mainly when you care about
> saving programming efforts and clean code.
you are saving a few lines of code by adding a lot of ambiguity. imho,
the trade off is not worth it. but we still make it possible for you
to shoot yourself in the foot if you choose to do so :)
-igor
>
>
> igor.vaynberg wrote:
>>
>> in our app components with id feedbackPanel are often used to present
>> a user with a user-feedback panel they can use to submit
>> suggestions...
>>
>> -igor
>>
>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>> <ri...@gmail.com> wrote:
>>>
>>> Hi Martijin,
>>> First of all thank you for your response.
>>> I guess automation != magic. Automation means that computers or
>>> frameworks
>>> helps humans accomplishing repetitive tasks, so developers can better
>>> focus
>>> on the problem being solved, rather than having to copy and paste same
>>> code
>>> over and over (boilerplate).
>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>> combo
>>> box? Or he have to tell it again, in a different way? IMO it's better to
>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>
>>>
>>> Martijn Dashorst wrote:
>>>>
>>>> -1000,000,000,000
>>>>
>>>> First please don't assume someone understands your acronym du jour. I
>>>> had to think really hard to understand that CoC means convention over
>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>
>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>> you want in your own addon framework and publish it on 'stuff or
>>>> google code, but I won't be using it ever nor including it in core.
>>>>
>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>> don't need nor want to have to wave a dead chicken in front of my
>>>> monitor and spend the bigger part of the day wondering which
>>>> incantation I did wrong.
>>>>
>>>> Martijn
>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>
>>>>> I started to use wicket some time ago, and I'm really enjoying it. Best
>>>>> framework ever.
>>>>> But I've some suggestions.
>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>> could
>>>>> be reduced by using CoC.
>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>> component
>>>>> on
>>>>> the web page, even if no special handling is requires (which is almost
>>>>> the
>>>>> case).
>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>> feedbackPanel, a feedbackpanel component is automatically added to that
>>>>> page.
>>>>> Another example is SubmitLink component. No special handling required,
>>>>> but
>>>>> for wicket sake the developer must add it on the java the page.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>> Apache Wicket 1.3.4 is released
>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Wicket and CoC
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Theres also wickettopia...
http://sourceforge.net/projects/wicketopia/
jWeekend wrote:
> Richardo,
>
> If you are serious about looking into RADifying extension to Wicket, here
> are a couple of resources that may be interesting:
>
> http://herebebeasties.com Al Maw' s excellent
> http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with
> Flair presentation
> http://faler.wordpress.com/ Wille Faler 's neat
> http://sites.google.com/site/wicketrad/ Wicket RAD project
> http://wicketwebbeans.sourceforge.net/ Wicket Web Beans (haven't met the
> author of this one)
>
> Regards - Cemal
> http://www.jWeekend.co.uk http://jWeekend.co.uk
>
>
>
>
> Ricardo Mayerhofer wrote:
>
>> Perhaps the name could be userFeedBackPanel :)
>> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>>
>> I'm just talking about code duplication, add( new SubmitLink( "submitLink"
>> ) ) and similars many times in a code doenst makes a programmer happier.
>> OOP (object oriented programming) isn't always the best tools to solve
>> code duplication. So sometimes AOP (aspect oriented programming) comes to
>> mind, other times CoC (convention over configuration). (I hope Martijn is
>> happy by the acronyms explanations :)).
>>
>> I'm not saying that it should be in wicket core (as you guys keep it thin
>> as you can) and I'm glad wicket core makes me able to extend it, in a way
>> I can implement this (thats a huge plus)
>>
>> I'm just saying that this is not a bad idea, mainly when you care about
>> saving programming efforts and clean code.
>>
>>
>> igor.vaynberg wrote:
>>
>>> in our app components with id feedbackPanel are often used to present
>>> a user with a user-feedback panel they can use to submit
>>> suggestions...
>>>
>>> -igor
>>>
>>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>>> <ri...@gmail.com> wrote:
>>>
>>>> Hi Martijin,
>>>> First of all thank you for your response.
>>>> I guess automation != magic. Automation means that computers or
>>>> frameworks
>>>> helps humans accomplishing repetitive tasks, so developers can better
>>>> focus
>>>> on the problem being solved, rather than having to copy and paste same
>>>> code
>>>> over and over (boilerplate).
>>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>>> combo
>>>> box? Or he have to tell it again, in a different way? IMO it's better to
>>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>>
>>>>
>>>> Martijn Dashorst wrote:
>>>>
>>>>> -1000,000,000,000
>>>>>
>>>>> First please don't assume someone understands your acronym du jour. I
>>>>> had to think really hard to understand that CoC means convention over
>>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>>
>>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>>> you want in your own addon framework and publish it on 'stuff or
>>>>> google code, but I won't be using it ever nor including it in core.
>>>>>
>>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>>> don't need nor want to have to wave a dead chicken in front of my
>>>>> monitor and spend the bigger part of the day wondering which
>>>>> incantation I did wrong.
>>>>>
>>>>> Martijn
>>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>
>>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>>> Best
>>>>>> framework ever.
>>>>>> But I've some suggestions.
>>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>>> could
>>>>>> be reduced by using CoC.
>>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>>> component
>>>>>> on
>>>>>> the web page, even if no special handling is requires (which is almost
>>>>>> the
>>>>>> case).
>>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>>> that
>>>>>> page.
>>>>>> Another example is SubmitLink component. No special handling required,
>>>>>> but
>>>>>> for wicket sake the developer must add it on the java the page.
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>> Apache Wicket 1.3.4 is released
>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>>
>>
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by wfaler <wi...@gmail.com>.
Speaking of which, I'd be happy to get help with Wicket RAD. :)
Especially in the area of making look-and-feel more customizable/flexible,
but other ideas are also welcome of course. Help with documentation would
also be very, very welcome. :D
Have a new release in the works, just been a bit snowed under of late. After
the next release I'm looking at upgrading the underlying Wicket
implementation to 1.4.
jWeekend wrote:
>
> Richardo,
>
> If you are serious about looking into RADifying extension to Wicket, here
> are a couple of resources that may be interesting:
>
> http://herebebeasties.com Al Maw' s excellent
> http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with
> Flair presentation
> http://faler.wordpress.com/ Wille Faler 's neat
> http://sites.google.com/site/wicketrad/ Wicket RAD project
> http://wicketwebbeans.sourceforge.net/ Wicket Web Beans (haven't met the
> author of this one)
>
> Regards - Cemal
> http://www.jWeekend.co.uk http://jWeekend.co.uk
>
>
>
>
> Ricardo Mayerhofer wrote:
>>
>> Perhaps the name could be userFeedBackPanel :)
>> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>>
>> I'm just talking about code duplication, add( new SubmitLink(
>> "submitLink" ) ) and similars many times in a code doenst makes a
>> programmer happier.
>> OOP (object oriented programming) isn't always the best tools to solve
>> code duplication. So sometimes AOP (aspect oriented programming) comes to
>> mind, other times CoC (convention over configuration). (I hope Martijn is
>> happy by the acronyms explanations :)).
>>
>> I'm not saying that it should be in wicket core (as you guys keep it thin
>> as you can) and I'm glad wicket core makes me able to extend it, in a way
>> I can implement this (thats a huge plus)
>>
>> I'm just saying that this is not a bad idea, mainly when you care about
>> saving programming efforts and clean code.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> in our app components with id feedbackPanel are often used to present
>>> a user with a user-feedback panel they can use to submit
>>> suggestions...
>>>
>>> -igor
>>>
>>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>>> <ri...@gmail.com> wrote:
>>>>
>>>> Hi Martijin,
>>>> First of all thank you for your response.
>>>> I guess automation != magic. Automation means that computers or
>>>> frameworks
>>>> helps humans accomplishing repetitive tasks, so developers can better
>>>> focus
>>>> on the problem being solved, rather than having to copy and paste same
>>>> code
>>>> over and over (boilerplate).
>>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>>> combo
>>>> box? Or he have to tell it again, in a different way? IMO it's better
>>>> to
>>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>>
>>>>
>>>> Martijn Dashorst wrote:
>>>>>
>>>>> -1000,000,000,000
>>>>>
>>>>> First please don't assume someone understands your acronym du jour. I
>>>>> had to think really hard to understand that CoC means convention over
>>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>>
>>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>>> you want in your own addon framework and publish it on 'stuff or
>>>>> google code, but I won't be using it ever nor including it in core.
>>>>>
>>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>>> don't need nor want to have to wave a dead chicken in front of my
>>>>> monitor and spend the bigger part of the day wondering which
>>>>> incantation I did wrong.
>>>>>
>>>>> Martijn
>>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>>
>>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>>> Best
>>>>>> framework ever.
>>>>>> But I've some suggestions.
>>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>>> could
>>>>>> be reduced by using CoC.
>>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>>> component
>>>>>> on
>>>>>> the web page, even if no special handling is requires (which is
>>>>>> almost
>>>>>> the
>>>>>> case).
>>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>>> that
>>>>>> page.
>>>>>> Another example is SubmitLink component. No special handling
>>>>>> required,
>>>>>> but
>>>>>> for wicket sake the developer must add it on the java the page.
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>> Apache Wicket 1.3.4 is released
>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20710787.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by jWeekend <jw...@cabouge.com>.
Richardo,
If you are serious about looking into RADifying extension to Wicket, here
are a couple of resources that may be interesting:
http://herebebeasties.com Al Maw' s excellent
http://londonwicket.org/content/LondonWicket-FormsWithFlair.pdf Forms with
Flair presentation
http://faler.wordpress.com/ Wille Faler 's neat
http://sites.google.com/site/wicketrad/ Wicket RAD project
http://wicketwebbeans.sourceforge.net/ Wicket Web Beans (haven't met the
author of this one)
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Ricardo Mayerhofer wrote:
>
> Perhaps the name could be userFeedBackPanel :)
> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>
> I'm just talking about code duplication, add( new SubmitLink( "submitLink"
> ) ) and similars many times in a code doenst makes a programmer happier.
> OOP (object oriented programming) isn't always the best tools to solve
> code duplication. So sometimes AOP (aspect oriented programming) comes to
> mind, other times CoC (convention over configuration). (I hope Martijn is
> happy by the acronyms explanations :)).
>
> I'm not saying that it should be in wicket core (as you guys keep it thin
> as you can) and I'm glad wicket core makes me able to extend it, in a way
> I can implement this (thats a huge plus)
>
> I'm just saying that this is not a bad idea, mainly when you care about
> saving programming efforts and clean code.
>
>
> igor.vaynberg wrote:
>>
>> in our app components with id feedbackPanel are often used to present
>> a user with a user-feedback panel they can use to submit
>> suggestions...
>>
>> -igor
>>
>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>> <ri...@gmail.com> wrote:
>>>
>>> Hi Martijin,
>>> First of all thank you for your response.
>>> I guess automation != magic. Automation means that computers or
>>> frameworks
>>> helps humans accomplishing repetitive tasks, so developers can better
>>> focus
>>> on the problem being solved, rather than having to copy and paste same
>>> code
>>> over and over (boilerplate).
>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>> combo
>>> box? Or he have to tell it again, in a different way? IMO it's better to
>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>
>>>
>>> Martijn Dashorst wrote:
>>>>
>>>> -1000,000,000,000
>>>>
>>>> First please don't assume someone understands your acronym du jour. I
>>>> had to think really hard to understand that CoC means convention over
>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>
>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>> you want in your own addon framework and publish it on 'stuff or
>>>> google code, but I won't be using it ever nor including it in core.
>>>>
>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>> don't need nor want to have to wave a dead chicken in front of my
>>>> monitor and spend the bigger part of the day wondering which
>>>> incantation I did wrong.
>>>>
>>>> Martijn
>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>
>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>> Best
>>>>> framework ever.
>>>>> But I've some suggestions.
>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>> could
>>>>> be reduced by using CoC.
>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>> component
>>>>> on
>>>>> the web page, even if no special handling is requires (which is almost
>>>>> the
>>>>> case).
>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>> that
>>>>> page.
>>>>> Another example is SubmitLink component. No special handling required,
>>>>> but
>>>>> for wicket sake the developer must add it on the java the page.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>> Apache Wicket 1.3.4 is released
>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20710279.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by jWeekend <jw...@cabouge.com>.
Richardo,
That's one way of thinking. And I agree Bob Martin has some interesting
generic ideas/guidelines for developers starting out.
I have a lot of faith in the Wicket core devs and I tend to agree with most
all the decisions they take (often after a lot of instructive and
constructive discussion). However, if it turns out that your ideas on this
matter and the implementation of it can save hours of developer time while
not reducing the quality of this (serious) framework or the experience, I am
sure I would make time to look at it.
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
Ricardo Mayerhofer wrote:
>
> Perhaps the name could be userFeedBackPanel :)
> "One Word per Concept" (Clean Code, Bob Martin, p. 26)
>
> I'm just talking about code duplication, add( new SubmitLink( "submitLink"
> ) ) and similars many times in a code doenst makes a programmer happier.
> OOP (object oriented programming) isn't always the best tools to solve
> code duplication. So sometimes AOP (aspect oriented programming) comes to
> mind, other times CoC (convention over configuration). (I hope Martijn is
> happy by the acronyms explanations :)).
>
> I'm not saying that it should be in wicket core (as you guys keep it thin
> as you can) and I'm glad wicket core makes me able to extend it, in a way
> I can implement this (thats a huge plus)
>
> I'm just saying that this is not a bad idea, mainly when you care about
> saving programming efforts and clean code.
>
>
> igor.vaynberg wrote:
>>
>> in our app components with id feedbackPanel are often used to present
>> a user with a user-feedback panel they can use to submit
>> suggestions...
>>
>> -igor
>>
>> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
>> <ri...@gmail.com> wrote:
>>>
>>> Hi Martijin,
>>> First of all thank you for your response.
>>> I guess automation != magic. Automation means that computers or
>>> frameworks
>>> helps humans accomplishing repetitive tasks, so developers can better
>>> focus
>>> on the problem being solved, rather than having to copy and paste same
>>> code
>>> over and over (boilerplate).
>>> If one add a markup named feedbackPanel, what is he intent, to make a
>>> combo
>>> box? Or he have to tell it again, in a different way? IMO it's better to
>>> tell one time what I'm willing to do rather than 2, 3, 5...
>>>
>>>
>>> Martijn Dashorst wrote:
>>>>
>>>> -1000,000,000,000
>>>>
>>>> First please don't assume someone understands your acronym du jour. I
>>>> had to think really hard to understand that CoC means convention over
>>>> configuration instead of the Dutch meaning "gay rights group".
>>>>
>>>> Second this is not a task for wicket. You can think up any CoCamania
>>>> you want in your own addon framework and publish it on 'stuff or
>>>> google code, but I won't be using it ever nor including it in core.
>>>>
>>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>>> don't need nor want to have to wave a dead chicken in front of my
>>>> monitor and spend the bigger part of the day wondering which
>>>> incantation I did wrong.
>>>>
>>>> Martijn
>>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>>
>>>>> I started to use wicket some time ago, and I'm really enjoying it.
>>>>> Best
>>>>> framework ever.
>>>>> But I've some suggestions.
>>>>> I think wicket could be better if it had less boiler plate code. This
>>>>> could
>>>>> be reduced by using CoC.
>>>>> Take the FeedBackPanel for example, you always have to add the
>>>>> component
>>>>> on
>>>>> the web page, even if no special handling is requires (which is almost
>>>>> the
>>>>> case).
>>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>>> feedbackPanel, a feedbackpanel component is automatically added to
>>>>> that
>>>>> page.
>>>>> Another example is SubmitLink component. No special handling required,
>>>>> but
>>>>> for wicket sake the developer must add it on the java the page.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>> Apache Wicket 1.3.4 is released
>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20709922.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
Perhaps the name could be userFeedBackPanel :)
"One Word per Concept" (Clean Code, Bob Martin, p. 26)
I'm just talking about code duplication, add( new SubmitLink( "submitLink" )
) and similars many times in a code doenst makes a programmer happier.
OOP (object oriented programming) isn't always the best tools to solve code
duplication. So sometimes AOP (aspect oriented programming) comes to mind,
other times CoC (convention over configuration). (I hope Martijn is happy by
the acronyms explanations :)).
I'm not saying that it should be in wicket core (as you guys keep it thin as
you can) and I'm glad wicket core makes me able to extend it, in a way I can
implement this (thats a huge plus)
I'm just saying that this is not a bad idea, mainly when you care about
saving programming efforts and clean code.
igor.vaynberg wrote:
>
> in our app components with id feedbackPanel are often used to present
> a user with a user-feedback panel they can use to submit
> suggestions...
>
> -igor
>
> On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
> <ri...@gmail.com> wrote:
>>
>> Hi Martijin,
>> First of all thank you for your response.
>> I guess automation != magic. Automation means that computers or
>> frameworks
>> helps humans accomplishing repetitive tasks, so developers can better
>> focus
>> on the problem being solved, rather than having to copy and paste same
>> code
>> over and over (boilerplate).
>> If one add a markup named feedbackPanel, what is he intent, to make a
>> combo
>> box? Or he have to tell it again, in a different way? IMO it's better to
>> tell one time what I'm willing to do rather than 2, 3, 5...
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> -1000,000,000,000
>>>
>>> First please don't assume someone understands your acronym du jour. I
>>> had to think really hard to understand that CoC means convention over
>>> configuration instead of the Dutch meaning "gay rights group".
>>>
>>> Second this is not a task for wicket. You can think up any CoCamania
>>> you want in your own addon framework and publish it on 'stuff or
>>> google code, but I won't be using it ever nor including it in core.
>>>
>>> The biggest plus point of wicket is that it doesn't perform magic. I
>>> don't need nor want to have to wave a dead chicken in front of my
>>> monitor and spend the bigger part of the day wondering which
>>> incantation I did wrong.
>>>
>>> Martijn
>>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>>
>>>> I started to use wicket some time ago, and I'm really enjoying it. Best
>>>> framework ever.
>>>> But I've some suggestions.
>>>> I think wicket could be better if it had less boiler plate code. This
>>>> could
>>>> be reduced by using CoC.
>>>> Take the FeedBackPanel for example, you always have to add the
>>>> component
>>>> on
>>>> the web page, even if no special handling is requires (which is almost
>>>> the
>>>> case).
>>>> Wicket could have some reserved ids, so if I add a markup with id
>>>> feedbackPanel, a feedbackpanel component is automatically added to that
>>>> page.
>>>> Another example is SubmitLink component. No special handling required,
>>>> but
>>>> for wicket sake the developer must add it on the java the page.
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> Apache Wicket 1.3.4 is released
>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20709706.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Igor Vaynberg <ig...@gmail.com>.
in our app components with id feedbackPanel are often used to present
a user with a user-feedback panel they can use to submit
suggestions...
-igor
On Wed, Nov 26, 2008 at 12:51 PM, Ricardo Mayerhofer
<ri...@gmail.com> wrote:
>
> Hi Martijin,
> First of all thank you for your response.
> I guess automation != magic. Automation means that computers or frameworks
> helps humans accomplishing repetitive tasks, so developers can better focus
> on the problem being solved, rather than having to copy and paste same code
> over and over (boilerplate).
> If one add a markup named feedbackPanel, what is he intent, to make a combo
> box? Or he have to tell it again, in a different way? IMO it's better to
> tell one time what I'm willing to do rather than 2, 3, 5...
>
>
> Martijn Dashorst wrote:
>>
>> -1000,000,000,000
>>
>> First please don't assume someone understands your acronym du jour. I
>> had to think really hard to understand that CoC means convention over
>> configuration instead of the Dutch meaning "gay rights group".
>>
>> Second this is not a task for wicket. You can think up any CoCamania
>> you want in your own addon framework and publish it on 'stuff or
>> google code, but I won't be using it ever nor including it in core.
>>
>> The biggest plus point of wicket is that it doesn't perform magic. I
>> don't need nor want to have to wave a dead chicken in front of my
>> monitor and spend the bigger part of the day wondering which
>> incantation I did wrong.
>>
>> Martijn
>> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>>
>>> I started to use wicket some time ago, and I'm really enjoying it. Best
>>> framework ever.
>>> But I've some suggestions.
>>> I think wicket could be better if it had less boiler plate code. This
>>> could
>>> be reduced by using CoC.
>>> Take the FeedBackPanel for example, you always have to add the component
>>> on
>>> the web page, even if no special handling is requires (which is almost
>>> the
>>> case).
>>> Wicket could have some reserved ids, so if I add a markup with id
>>> feedbackPanel, a feedbackpanel component is automatically added to that
>>> page.
>>> Another example is SubmitLink component. No special handling required,
>>> but
>>> for wicket sake the developer must add it on the java the page.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>> Apache Wicket 1.3.4 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Wicket and CoC
Posted by Jeremy Thomerson <je...@wickettraining.com>.
You can also add it to your base page and include it in any page you want,
or include it in your base page layout - now it's automatically on every
page. In other words, everyone may want to do something a different way, so
there's no reason the framework should do it automatically your way - but it
should make it easy for you to do it yourself - which it does.
On Wed, Nov 26, 2008 at 2:51 PM, Ricardo Mayerhofer <
ricardo.ekm.listas@gmail.com> wrote:
>
> Hi Martijin,
> First of all thank you for your response.
> I guess automation != magic. Automation means that computers or frameworks
> helps humans accomplishing repetitive tasks, so developers can better focus
> on the problem being solved, rather than having to copy and paste same code
> over and over (boilerplate).
> If one add a markup named feedbackPanel, what is he intent, to make a combo
> box? Or he have to tell it again, in a different way? IMO it's better to
> tell one time what I'm willing to do rather than 2, 3, 5...
>
>
> Martijn Dashorst wrote:
> >
> > -1000,000,000,000
> >
> > First please don't assume someone understands your acronym du jour. I
> > had to think really hard to understand that CoC means convention over
> > configuration instead of the Dutch meaning "gay rights group".
> >
> > Second this is not a task for wicket. You can think up any CoCamania
> > you want in your own addon framework and publish it on 'stuff or
> > google code, but I won't be using it ever nor including it in core.
> >
> > The biggest plus point of wicket is that it doesn't perform magic. I
> > don't need nor want to have to wave a dead chicken in front of my
> > monitor and spend the bigger part of the day wondering which
> > incantation I did wrong.
> >
> > Martijn
> > On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
> >>
> >> I started to use wicket some time ago, and I'm really enjoying it. Best
> >> framework ever.
> >> But I've some suggestions.
> >> I think wicket could be better if it had less boiler plate code. This
> >> could
> >> be reduced by using CoC.
> >> Take the FeedBackPanel for example, you always have to add the component
> >> on
> >> the web page, even if no special handling is requires (which is almost
> >> the
> >> case).
> >> Wicket could have some reserved ids, so if I add a markup with id
> >> feedbackPanel, a feedbackpanel component is automatically added to that
> >> page.
> >> Another example is SubmitLink component. No special handling required,
> >> but
> >> for wicket sake the developer must add it on the java the page.
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.3.4 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Jeremy Thomerson
http://www.wickettraining.com
Re: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
Hi Martijin,
First of all thank you for your response.
I guess automation != magic. Automation means that computers or frameworks
helps humans accomplishing repetitive tasks, so developers can better focus
on the problem being solved, rather than having to copy and paste same code
over and over (boilerplate).
If one add a markup named feedbackPanel, what is he intent, to make a combo
box? Or he have to tell it again, in a different way? IMO it's better to
tell one time what I'm willing to do rather than 2, 3, 5...
Martijn Dashorst wrote:
>
> -1000,000,000,000
>
> First please don't assume someone understands your acronym du jour. I
> had to think really hard to understand that CoC means convention over
> configuration instead of the Dutch meaning "gay rights group".
>
> Second this is not a task for wicket. You can think up any CoCamania
> you want in your own addon framework and publish it on 'stuff or
> google code, but I won't be using it ever nor including it in core.
>
> The biggest plus point of wicket is that it doesn't perform magic. I
> don't need nor want to have to wave a dead chicken in front of my
> monitor and spend the bigger part of the day wondering which
> incantation I did wrong.
>
> Martijn
> On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>>
>> I started to use wicket some time ago, and I'm really enjoying it. Best
>> framework ever.
>> But I've some suggestions.
>> I think wicket could be better if it had less boiler plate code. This
>> could
>> be reduced by using CoC.
>> Take the FeedBackPanel for example, you always have to add the component
>> on
>> the web page, even if no special handling is requires (which is almost
>> the
>> case).
>> Wicket could have some reserved ids, so if I add a markup with id
>> feedbackPanel, a feedbackpanel component is automatically added to that
>> page.
>> Another example is SubmitLink component. No special handling required,
>> but
>> for wicket sake the developer must add it on the java the page.
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20708778.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Martijn Dashorst <ma...@gmail.com>.
-1000,000,000,000
First please don't assume someone understands your acronym du jour. I
had to think really hard to understand that CoC means convention over
configuration instead of the Dutch meaning "gay rights group".
Second this is not a task for wicket. You can think up any CoCamania
you want in your own addon framework and publish it on 'stuff or
google code, but I won't be using it ever nor including it in core.
The biggest plus point of wicket is that it doesn't perform magic. I
don't need nor want to have to wave a dead chicken in front of my
monitor and spend the bigger part of the day wondering which
incantation I did wrong.
Martijn
On 11/26/08, Ricardo Mayerhofer <ri...@gmail.com> wrote:
>
> I started to use wicket some time ago, and I'm really enjoying it. Best
> framework ever.
> But I've some suggestions.
> I think wicket could be better if it had less boiler plate code. This could
> be reduced by using CoC.
> Take the FeedBackPanel for example, you always have to add the component on
> the web page, even if no special handling is requires (which is almost the
> case).
> Wicket could have some reserved ids, so if I add a markup with id
> feedbackPanel, a feedbackpanel component is automatically added to that
> page.
> Another example is SubmitLink component. No special handling required, but
> for wicket sake the developer must add it on the java the page.
> --
> View this message in context:
> http://www.nabble.com/Wicket-and-CoC-tp20706881p20706881.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Ricardo Mayerhofer <ri...@gmail.com>.
Thanks Sven! I will look into it.
svenmeier wrote:
>
> With IComponentResolver you can easily roll your own 'CoC' solution.
>
> Sven
>
> Ricardo Mayerhofer schrieb:
>> I started to use wicket some time ago, and I'm really enjoying it. Best
>> framework ever.
>> But I've some suggestions.
>> I think wicket could be better if it had less boiler plate code. This
>> could
>> be reduced by using CoC.
>> Take the FeedBackPanel for example, you always have to add the component
>> on
>> the web page, even if no special handling is requires (which is almost
>> the
>> case).
>> Wicket could have some reserved ids, so if I add a markup with id
>> feedbackPanel, a feedbackpanel component is automatically added to that
>> page.
>> Another example is SubmitLink component. No special handling required,
>> but
>> for wicket sake the developer must add it on the java the page.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Wicket-and-CoC-tp20706881p20708568.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket and CoC
Posted by Sven Meier <sv...@meiers.net>.
With IComponentResolver you can easily roll your own 'CoC' solution.
Sven
Ricardo Mayerhofer schrieb:
> I started to use wicket some time ago, and I'm really enjoying it. Best
> framework ever.
> But I've some suggestions.
> I think wicket could be better if it had less boiler plate code. This could
> be reduced by using CoC.
> Take the FeedBackPanel for example, you always have to add the component on
> the web page, even if no special handling is requires (which is almost the
> case).
> Wicket could have some reserved ids, so if I add a markup with id
> feedbackPanel, a feedbackpanel component is automatically added to that
> page.
> Another example is SubmitLink component. No special handling required, but
> for wicket sake the developer must add it on the java the page.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org