Re: WICKET-6514 and FeedbackPanel

[Martin Makundi]

What is the reasoning behind the "design" of not showing session level
feedback messages?

**
Martin

2018-01-04 4:41 GMT+02:00 Maxim Solodovnik :

> I thought this API break was "by design"
> Maybe this can be documented instead?
>
> WBR, Maxim
> (from mobile, sorry for the typos)
>
> On Thu, Jan 4, 2018, 05:22 Martijn Dashorst 
> wrote:
>
> > On Wed, Jan 3, 2018 at 10:43 PM, Andrea Del Bene 
> > wrote:
> > > Hi,
> > >
> > > as a result of WICKET-6514 now FeedbackPanel doesn't show anymore
> session
> > > messages. I'm not sure if this was intentional, but I think
> > FeedbackPanel
> > > shouldn't change its behavior. Should we modify FeedbackPanel to
> restore
> > the
> > > original behavior?
> >
> > Yes. There are countless applications depending on this type of
> > messaging. This is a regression.
> >
> > Martijn
> >
>

Re: 8.0.0 blockers

[Martin Makundi]

If configuration option is final solution then yes, otherwise it opens a
new can of worms for backwards (and on-site branching) compatibility.

**
Martin
+0.02

2018-01-02 12:29 GMT+02:00 Korbinian Bachl :

> May I ask why not a simple Config option? When disabled current behaviour
> (default) but when turned on new behaviour? That way it wont break anything
> and may be added to wicket any time?
>
> I just ask because this "not in that version" etc. usually is the reason
> why some Frameworks seems less active/ agile as others. Maybe I miss the
> big picture but I really would hate it if I have to wait for a new major
> version of wicket each time we need to keep up with the developement of the
> browsers... long time ago there was a discussion what version of jQuery
> should be in wicket and it went on 2, a sane idea at that time, but now as
> its 2018 I - for example - would instead now only ship JQuery 3.x default
> for wicket as the time has changed.
> I wonder how wicket will keep up with that if the cycle is so long each
> time...
>
> Best
>
> KB
>
> PS: I know that you can override the jQuery version as you like, it is
> just an example how the "best idea/ way to do it" changes over time
>
> - Ursprüngliche Mail -
> > Von: "Sven Meier" 
> > An: dev@wicket.apache.org
> > Gesendet: Dienstag, 2. Januar 2018 10:57:39
> > Betreff: Re: 8.0.0 blockers
>
> > Hi Maxim,
> >
> > I don't think WICKET-6498 will be part of Wicket 8:
> > There are still conceptual open questions (who decides what resources to
> defer)
> > and implementation issues, i.e. does the proposed solution with
> > addEventListener work in all browsers.
> >
> > Thanks for testing this.
> > Sven
> >
> > ⁣Gesendet mit Blue
> >
> > Am 2. Jan. 2018, 09:13, um 09:13, Maxim Solodovnik  >
> > schrieb:
> >>I'll try to test WICKET-6498 today/tomorrow
> >>
> >>On Sun, Dec 31, 2017 at 5:04 PM, Martijn Dashorst <
> >>martijn.dasho...@gmail.com> wrote:
> >>
> >>> I’m working on restyling the QuickStart to look like the new
> >>examples. Not
> >>> a blocker but would be awesome to include. Will work on it 2nd Jan
> >>>
> >>> Martijn
> >>>
> >>>
> >>>
> >>> Op vr 29 dec. 2017 om 20:28 schreef Korbinian Bachl <
> >>> korbinian.ba...@whiskyworld.de>
> >>>
> >>> > May I also mention WICKET-6498?
> >>> >
> >>> > https://issues.apache.org/jira/browse/WICKET-6498
> >>> >
> >>> >
> >>> >
> >>> > - Ursprüngliche Mail -
> >>> > > Von: "Sven Meier" 
> >>> > > An: dev@wicket.apache.org
> >>> > > Gesendet: Freitag, 29. Dezember 2017 16:22:47
> >>> > > Betreff: Re: 8.0.0 blockers
> >>> >
> >>> > > Not strictly necessary, but I would like to merge WICKET-6503:
> >>> > >
> >>> > > https://issues.apache.org/jira/browse/WICKET-6503
> >>> > >
> >>> > > Have fun
> >>> > > Sven
> >>> > >
> >>> > >
> >>> > > Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
> >>> > >> Hello All,
> >>> > >>
> >>> > >> Is it time for release?
> >>> > >>
> >>> > >> There are long holidays upcoming here, so I can send more time
> >>on
> >>> Wicket
> >>> > >> :)))
> >>> > >>
> >>> > >>
> >>> > >> On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene <
> >>> an.delb...@gmail.com>
> >>> > >> wrote:
> >>> > >>
> >>> > >>> On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
> >>> > >>> martijn.dasho...@gmail.com> wrote:
> >>> > >>>
> >>> >  No technical blockers AFAIK, however, we really should do the
> >>> > marketing
> >>> >  right:
> >>> > 
> >>> >  - front page of website should feature 8 prominently
> >>> >  - work with Sally from PR for a press release to let the world
> >>know
> >>> we
> >>> > >>> are
> >>> >  not Dead Yet™
> >>> >  - have a really great announcement to give to the world about
> >>all
> >>> the
> >>> >  benefits of Wicket 8
> >>> > 
> >>> >  What are the key features that necessitate upgrading to Wicket
> >>8?
> >>> > 
> >>> >  Not blocking but really important:
> >>> > 
> >>> >  - have a story to answer "Why not just use XXX.js?"
> >>> >  - have a story to answer "Isn't Java Server Side frameworks
> >>dead?"
> >>> > 
> >>> > >>> I (partially) covered these two issues in my presentation.
> >>Maybe it
> >>> > can be
> >>> > >>> helpful for further considerations:
> >>> > >>>
> >>> > >>> http://events.linuxfoundation.org/sites/events/files/slides/
> >>> > >>> Wicket_The_story_so_far_and_beyond.pdf
> >>> > >>>
> >>> > >>>
> >>> >  - have a story to answer "Isn't Java dead"
> >>> > 
> >>> > >>> Java will never die :-)
> >>> > >>>
> >>> > >>>
> >>> >  Have a call list for when a reporter wants to have contact
> >>about
> >>> > Wicket 8
> >>> >  and its future (esp. related to questions above)
> >>> > 
> >>> >  Other things to consider:
> >>> > 
> >>> >  - prepare some articles to publish to dzone, voxxed, etc.?
> >>> > 
> >>> > >>> I'm preparing an article for dzone. You can find it 

Re: 8.0.0 blockers

[Martin Makundi]

+1

2017-12-29 17:22 GMT+02:00 Sven Meier :

> Not strictly necessary, but I would like to merge WICKET-6503:
>
> https://issues.apache.org/jira/browse/WICKET-6503
>
> Have fun
> Sven
>
>
> Am 29.12.2017 um 06:02 schrieb Maxim Solodovnik:
>
>> Hello All,
>>
>> Is it time for release?
>>
>> There are long holidays upcoming here, so I can send more time on Wicket
>> :)))
>>
>>
>> On Thu, Nov 30, 2017 at 9:36 PM, Andrea Del Bene 
>> wrote:
>>
>> On Thu, Nov 30, 2017 at 1:07 PM, Martijn Dashorst <
>>> martijn.dasho...@gmail.com> wrote:
>>>
>>> No technical blockers AFAIK, however, we really should do the marketing
 right:

 - front page of website should feature 8 prominently
 - work with Sally from PR for a press release to let the world know we

>>> are
>>>
 not Dead Yet™
 - have a really great announcement to give to the world about all the
 benefits of Wicket 8

 What are the key features that necessitate upgrading to Wicket 8?

 Not blocking but really important:

 - have a story to answer "Why not just use XXX.js?"
 - have a story to answer "Isn't Java Server Side frameworks dead?"

 I (partially) covered these two issues in my presentation. Maybe it can
>>> be
>>> helpful for further considerations:
>>>
>>> http://events.linuxfoundation.org/sites/events/files/slides/
>>> Wicket_The_story_so_far_and_beyond.pdf
>>>
>>>
>>> - have a story to answer "Isn't Java dead"

 Java will never die :-)
>>>
>>>
>>> Have a call list for when a reporter wants to have contact about Wicket 8
 and its future (esp. related to questions above)

 Other things to consider:

 - prepare some articles to publish to dzone, voxxed, etc.?

 I'm preparing an article for dzone. You can find it here:
>>>
>>> https://www.dropbox.com/s/l9ec2plxyhe4aa2/article8.txt
>>>
>>> Any feedback is welcome!
>>>
>>>
>>> Martijn


 On Wed, Nov 29, 2017 at 3:32 AM, Maxim Solodovnik 
 wrote:

 Hello All,
>
> do we have any blockers for 8.0.0?
>
>
> --
> WBR
> Maxim aka solomax
>
>

 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com


>>
>>
>

Re: How to automatically log access to data objects in wicket gui

[Martin Makundi]

> I think you will need custom specialization of those models anyway.
> You will need to decide somehow when to apply your logic and when not.
>

True, but a nice boilerplate template would be nice, we could call it "The
GDPR compliance <https://www.eugdpr.org/> model" ;)

It could have methods like isAuthorized before invoking get or set and log
if not authorized and throw exception.

When model access is authroized, it would have methods like logAccess()
which will log (as necessary) how and what is accessed. Logging
implementation will take care of optimizing frequent logs etc.

Possibly it could be applied to both propertymodel and lamba model as a
"model behavior" or something.

I made a jira proposal and we will submit something soon:
https://issues.apache.org/jira/browse/WICKET-6508

**
Martin


>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Dec 15, 2017 at 2:20 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
> > Thanks
> >
> > We don't want to log ALL invocations, only those in particular wicket
> > imodels. Aspect will give you all like a profiler, that's not what we
> want
> > and it would not have natural visibility to wicket session.
> >
> > Or do you have a specific example in mind?
> >
> > **
> > Martin
> >
> > 2017-12-15 9:54 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>:
> >
> > > Hi,
> > >
> > > You can use Aspect Oriented Programming for this too.
> > > See wicket-metrics module for example.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Fri, Dec 15, 2017 at 7:57 AM, Martin Makundi <
> > > martin.maku...@koodaripalvelut.com> wrote:
> > >
> > > > Hi!
> > > >
> > > > We are investigating ways to automatically log access to data objects
> > in
> > > > wicket gui.
> > > >
> > > > Oldschool solutions would be, for example to override/customize
> > > > PropertyModel and log target object and method invoked, and possibly
> > > result
> > > > value, together with necessary information from session (timestamp,
> > user
> > > > id, authorization level, etc.).
> > > >
> > > > However, with wicket 8 and java 8 lambda possibilities, I am
> wondering
> > if
> > > > anybody would have some ingenious suggestion how to do this very
> nicely
> > > by
> > > > implementing own AuditTrailSerializableFunction or similar?
> > > >
> > > > Might need to wrap the data objects in some sort of proxy but that
> > would
> > > be
> > > > ok:
> > > >
> > > >- https://gist.github.com/jhorstmann/de367a42a08d8deb8df9
> > > >-
> > > >https://stackoverflow.com/questions/13356326/how-can-i-
> > > > log-every-method-called-in-a-class-automatically-with-log4j
> > > >-
> > > >https://stackoverflow.com/questions/3291637/
> > > alternatives-to-java-lang-
> > > > reflect-proxy-for-creating-proxies-of-abstract-classes
> > > >
> > > >
> > > > Any suggestions?
> > > >
> > > > Would be cool if blueprints for this were built into wicket.
> > > >
> > > > Thanks.
> > > >
> > > > **
> > > > Martin
> > > >
> > >
> >
>

Re: Ajax refresh and feedback panel

[Martin Makundi]

>
>
> The question is not very clear (to me).
>
> I've closed your ticket for the same reason.
> Please try to clarify the problem or the feature here (or at dev@) before
> creating tickets!
>

My apologies for a brief ticket. Let's try to elaborate: In Component you
have special processing for IFeedback components using FEEDBACK_LIST
because when other components are rendered, they might throw feedback
messages and make feedback visible.

If feedback is rendered before other components (or in undetermined order),
the feedback might be rendered before another component has thrown a
message.

This is why the IFeedback components are rendered last in normal rendering.

However, in ajax update, such orderinf for IFeedback is not enforced.

I am proposing to add such reordering for ajax update also.

Thanks.

Plese let me know if this requires more clarification. Probably the
existing test case for normal rendering (if such exists) could be modified
for testing the same with ajax update.

**
Martin


> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Dec 2, 2017 at 3:15 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
> > Hi!
> >
> > For normal rendering we have:
> >
> > /**
> > * We need to postpone calling beforeRender() on components that implement
> > {@link IFeedback}, to
> > * be sure that all other component's beforeRender() has been already
> > called, so that IFeedbacks
> > * can collect all feedback messages. This is the key under list of
> > postponed {@link IFeedback}
> > * is stored to request cycle metadata. The List is then iterated over in
> > * {@link #prepareForRender()} after calling {@link #beforeRender()}, to
> > initialize postponed
> > * components.
> > */
> > private static final MetaDataKey<List> FEEDBACK_LIST = new
> > MetaDataKey<List>()
> > {
> > private static final long serialVersionUID = 1L;
> > };
> >
> > Should there be similar functionality built in for Ajax update /
> > PartialPageUpdate? It seems to be a typical problem that the feedback of
> an
> > ajax update occurs too late.
> >
> > https://issues.apache.org/jira/browse/WICKET-6503
> >
> > **
> > Martin
> >
>

Re: Multi-tab / window support in Wicket 7.5

[Martin Makundi]

If one makes a single-page application that has multiple tabs (within one
browser window), and you do not want to make custom logic to allow multi
window/tab (in browser) management into session, it would work best if
there was separate "session" for each browser tab/window inside wicket.

Simplest example is that session has variable "currentlySelectedTab" if you
have two browser windows open both will be racing for this same variable
unless sessions are separated.

So from developer's perspective, would be simplest if wicket transparently
separates sessions for each browser window/tab.

**
Martin



2016-12-07 14:19 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>:

> Hi,
>
> What kind of problem exactly you try to solve there ?
> What kind of issues do you face ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Dec 7, 2016 at 12:07 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
> > This should be built into wicket core, automatic session management.
> Login
> > once and enable multiple tabs and a new sub-session for each tab.
> >
> > If user logs out from any of the sessions, all would be invalidated.
> >
> > Not sure if this exists yet, but would be needed.
> >
> > **
> > Martin
> >
> > 2016-12-07 12:59 GMT+02:00 Urbani, Edmund <edmund.urb...@lilandit.com>:
> >
> > > Ok, but how do you create a session per tab? Also, I would at least
> need
> > > to login the authenticated user in the new session.
> > >
> > >
> > > On 12/07/2016 11:43 AM, Martin Makundi wrote:
> > >
> > > We have noticed that most robust if you can get different session for
> > each
> > > tab because the session shares models and will easily conflict if
> session
> > > is not distinct for each tab.
> > >
> > >
> > >
> > > 2016-12-07 12:42 GMT+02:00 Urbani, Edmund <edmund.urb...@lilandit.com>
> <
> > edmund.urb...@lilandit.com>:
> > >
> > >
> > > Hi all,
> > >
> > > I have a some questions about the current state of this feature.
> > >
> > > Firstly, how reliable is it? (Works on all/current browsers? Can still
> > > break under certain circumstances?)
> > >
> > > And secondly, how would I store my own state information per
> tab/window?
> > > The session context seems too broad because it is shared by all tabs
> and
> > > the page context is too limited.
> > >
> > > I could make it work with the session anyway, if I can somehow identify
> > > the current browser tab and put things into a map accordingly. Or I
> could
> > > pass on all required info from page to page which would be quite
> > cumbersome
> > > and conflict with my approach to use bookmarkable URLs wherever
> possible.
> > >
> > > Kind regards,
> > >  Edmund
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > >
> > >
> > > --
> > >
> > > Edmund Urbani
> > > Liland IT Team
> > >
> > > Email: edmund.urb...@lilandit.com <edmund.urb...@lilandit.com>
> > >
> > > Liland IT GmbH ...does IT better
> > > Tel: +43 463 220111
> > > Fax: +43 463 220111-33
> > > Tel(GER): +49 221 65028588
> > >
> > > Find us at Facebook http://facebook.com/Lilandit
> > > http://iventcloud.com
> > > http://Lilandit.com
> > >
> > > <http://www.LilandIT.com> <http://www.LilandIT.com>
> > >
> > > Copyright © 2016, Liland IT GmbH
> > >
> > > Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> > > Informationen.
> > > Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich
> > > erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten
> > > Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
> > > dieser Mail ist nicht gestattet.
> > >
> > > This email may contain confidential and/or privileged information.
> > > If you are not the intended recipient (or have received this email in
> > > error) please notify the sender immediately and destroy this email. Any
> > > unauthorised copying, disclosure or distribution of the material in
> this
> > > email is strictly forbidden.
> > >
> >
>

Re: Multi-tab / window support in Wicket 7.5

[Martin Makundi]

This should be built into wicket core, automatic session management. Login
once and enable multiple tabs and a new sub-session for each tab.

If user logs out from any of the sessions, all would be invalidated.

Not sure if this exists yet, but would be needed.

**
Martin

2016-12-07 12:59 GMT+02:00 Urbani, Edmund <edmund.urb...@lilandit.com>:

> Ok, but how do you create a session per tab? Also, I would at least need
> to login the authenticated user in the new session.
>
>
> On 12/07/2016 11:43 AM, Martin Makundi wrote:
>
> We have noticed that most robust if you can get different session for each
> tab because the session shares models and will easily conflict if session
> is not distinct for each tab.
>
>
>
> 2016-12-07 12:42 GMT+02:00 Urbani, Edmund <edmund.urb...@lilandit.com> 
> <edmund.urb...@lilandit.com>:
>
>
> Hi all,
>
> I have a some questions about the current state of this feature.
>
> Firstly, how reliable is it? (Works on all/current browsers? Can still
> break under certain circumstances?)
>
> And secondly, how would I store my own state information per tab/window?
> The session context seems too broad because it is shared by all tabs and
> the page context is too limited.
>
> I could make it work with the session anyway, if I can somehow identify
> the current browser tab and put things into a map accordingly. Or I could
> pass on all required info from page to page which would be quite cumbersome
> and conflict with my approach to use bookmarkable URLs wherever possible.
>
> Kind regards,
>  Edmund
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
> --
>
> Edmund Urbani
> Liland IT Team
>
> Email: edmund.urb...@lilandit.com <edmund.urb...@lilandit.com>
>
> Liland IT GmbH ...does IT better
> Tel: +43 463 220111
> Fax: +43 463 220111-33
> Tel(GER): +49 221 65028588
>
> Find us at Facebook http://facebook.com/Lilandit
> http://iventcloud.com
> http://Lilandit.com
>
> <http://www.LilandIT.com> <http://www.LilandIT.com>
>
> Copyright © 2016, Liland IT GmbH
>
> Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten
> Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
> dieser Mail ist nicht gestattet.
>
> This email may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this email in
> error) please notify the sender immediately and destroy this email. Any
> unauthorised copying, disclosure or distribution of the material in this
> email is strictly forbidden.
>

Help in completing task

[Martin Makundi]

Hi!

We are looking to hire somebody to help us complete
https://issues.apache.org/jira/browse/WICKET-6177

Anyone?

Thanks.

**
Martin

Blocking page serialization

[Martin Makundi]

Hi!

https://issues.apache.org/jira/browse/WICKET-6177

We have a performance issue with our Wicket app, page serialization causes
inconvenience to user because PageStoreManager.storeTouchedPages() blocks
the request until pageSerializer.serialize(page) has been handled.

Could this be solved by serializing the page in a separate thread and let
the request complete?

We have attempted to solve this before for 1.4x but it failed due to
thread-dependenciecs:  https://issues.apache.org/jira/browse/WICKET-5805

Any ideas how this could be solved with 7.x? This would bring a significant
performance boost on component-intensive pages. Simply using detachable
models does not solve the issue when the serialization of the component
hierarchy itself is slow.

Thanks.

**
Martin

Re: Ideas for wicket 7.0

[Martin Makundi]

();
if (AjaxRequestTarget.get() != null) {
  getComponent().add(new AttributeAppender(class,true, new
AbstractReadOnlyModelString() {
/**
 * @see org.apache.wicket.model.AbstractReadOnlyModel#getObject()
 */
@SuppressWarnings(synthetic-access)
@Override
public String getObject() {
  if (FakeEventListener.get() == null) {

AjaxRequestTarget.get().addListener(FakeEventListener.getCreate());
  }
  return FACB+
FakeEventListener.get().index(FakeAjaxFormComponentUpdatingBehavior.this.parentMarkupId);
}
  },  ));
  getComponent().add(new AttributeModifier(bs,true,
Model.of(busySignal)));
}
  }


  /**
   *
   * @param target
   */
  public void fireOnEvent(AjaxRequestTarget target) {
onEvent(target);
  }




  /**
   * @see
org.apache.wicket.behavior.AbstractAjaxBehavior#onComponentRendered()
   */
  @Override
  protected void onComponentRendered() {
super.onComponentRendered();
String event = getEvent();
Component component = getComponent();
if(!isCollectScripts()) {
  onComponentRendered(event, component);
}
  }

  /**
   * @see
org.apache.wicket.ajax.AjaxEventBehavior#onComponentTag(org.apache.wicket.markup.ComponentTag)
   */
  @Override
  protected void onComponentTag(ComponentTag tag) {
if(!isCollectScripts()) {
  super.onComponentTag(tag);
}
  }

  /**
   * @param event
   * @param component
   */
  protected static void onComponentRendered(String event, Component
component) {
JavascriptUtils.writeOpenTag(component.getResponse());
component.getResponse().write($('# + component.getMarkupId() +
').change(function() { eval($(this).attr(' + event + ')); }););
JavascriptUtils.writeCloseTag(component.getResponse());
  }

  /**
   * @return Should scripts be collected.
   */
  protected final boolean isCollectScripts() {
return isCollectString;
  }

  /**
   * @see
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#renderHead(org.apache.wicket.markup.html.IHeaderResponse)
   */
  @Override
  public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderJavascriptReference(JavaScriptConstants.JS_JQUERY);
if(isCollectScripts()  AjaxRequestTarget.get() != null) {
  response.renderJavascriptReference(FakeAjaxCheckBox.JS);
  if (FakeEventListener.get() == null) {
AjaxRequestTarget.get().addListener(FakeEventListener.getCreate());
  }
  FakeEventListener.get().addScript(parentMarkupId);
}
  }

  /**
   *
   * @param target
   */
  protected abstract void onUpdate(AjaxRequestTarget target);

  /**
   *
   * @return Click script.
   */
  protected String getOnClickScript() {
CharSequence onClickScript = $('# + parentMarkupId + ').trigger(' +
FAKE_EVENT_NAME + ', ' + getComponent().getMarkupId() + '); return 
+ busySignal + ;;
IAjaxCallDecorator decorator = getDecorator();
if (decorator != null) {
  onClickScript = decorator.decorateScript(onClickScript);
} else if (AjaxRequestTarget.get() != null) {
  return null;
}
return onClickScript.toString();
  }



  /**
   * Get decorator. Only {@link
IAjaxCallDecorator#decorateScript(CharSequence)}
   * is used here!
   *
   * @return {@link IAjaxCallDecorator}
   */
  protected IAjaxCallDecorator getDecorator() {
return null;
  }

  /**
   * @return the parentMarkupId
   */
  public String getParentMarkupId() {
return parentMarkupId;
  }

  /**
   * @param parentMarkupId the parentMarkupId to set
   */
  public void setParentMarkupId(String parentMarkupId) {
this.parentMarkupId = parentMarkupId;
  }

  /**
   * @return the isCollectString
   */
  public boolean isCollectString() {
return isCollectString;
  }

  /**
   * @param isCollectString the isCollectString to set
   */
  public void setCollectString(boolean isCollectString) {
this.isCollectString = isCollectString;
  }

  /**
   * @return the busySignal
   */
  public boolean isBusySignal() {
return busySignal;
  }

}




**
Martin


 On Jan 10, 2015 4:43 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  Hi!
 
  I tried to add and idea to
  https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0
 
  However I cannot find any edit buttons when Logged in to confluence. The
  contribution page says anybody can contribute?
 
  My idea is related to Better stateless support
  
 
 https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0#IdeasforWicket7.0-Betterstatelesssupport
  
  :
 
 
 - Wicket seems to have this inherent MVC design flaw that it's View is
 stateful when it would really be sufficient that the Model is stateful
  and
 it does not (and neither does controller) need to be serialized.
 - It is possible to tweak to implement stateless View but it's quite a
 hack because most event listeners are attached to the hierarcy instead
  of
 page root which would have avoided the need to keep

Ideas for wicket 7.0

[Martin Makundi]

Hi!

I tried to add and idea to
https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0

However I cannot find any edit buttons when Logged in to confluence. The
contribution page says anybody can contribute?

My idea is related to Better stateless support
https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+7.0#IdeasforWicket7.0-Betterstatelesssupport
:


   - Wicket seems to have this inherent MVC design flaw that it's View is
   stateful when it would really be sufficient that the Model is stateful and
   it does not (and neither does controller) need to be serialized.
   - It is possible to tweak to implement stateless View but it's quite a
   hack because most event listeners are attached to the hierarcy instead of
   page root which would have avoided the need to keep/serialize state of the
   view. We have prototypes of FakeAjaxEventBehavior which is bound to page
   instead of a component; the component event thus invokes the page-level
   listener (on gui side) and thus in event processing (page level) we don't
   need the component itself nor its state.
   - Form components, however, are difficult to implement because they
   inherently have state in view, but on the other hand it is rare (and
   impractical) to actually have 'huge' forms; any such large editing areas
   will need to be 'worked around' some another way.


**
Martin

Re: Ideas for wicket 7.0

[Martin Makundi]

 IBehavior behavior : parent.getBehaviors()) {
  if (behavior instanceof ParameterizedFakeAjaxEventBehavior) { // TODO
// event
//
handler
// per
page? TODO Problem with refresh/repaint/appending handlers partially? Or
not?
((ParameterizedFakeAjaxEventBehavior)
behavior).addEventHandler(markupId, handler);
  }
}
  }
}



With usage example:

public class ParameterizedFakeEventButton extends Button {
  private final Component parent;
  private final String parameter;
  private final boolean busySignal;

  /**
   * @param id
   * @param parent
   * @param handler
   * @param busySignal
   */
  public ParameterizedFakeEventButton(String id, Component parent,
ParameterizedFakeAjaxEventBehavior.FakeEventHandler handler, boolean
busySignal) {
this(id, null, parent, handler, busySignal);
  }

  /**
   * @param id
   * @param model
   * @param parent
   * @param handler
   * @param busySignal
   */
  @SuppressWarnings(synthetic-access)
  public ParameterizedFakeEventButton(String id, ModelString model,
Component parent, ParameterizedFakeAjaxEventBehavior.FakeEventHandler
handler, boolean busySignal) {
super(id, model);
this.busySignal = busySignal;

setOutputMarkupId(ParameterizedFakeAjaxEventBehavior.MARKUP_ID_IDENTIFIES_EVENT);
setDefaultFormProcessing(false);
ParameterizedFakeAjaxEventBehavior.attach(parent, getMarkupId(),
handler);
this.parameter = handler.getConfirmScriptParameter();
this.parent = parent;
handler.setTargetComponent(this);
  }

  /**
   * @see org.apache.wicket.markup.html.form.Button#getOnClickScript()
   */
  @Override
  protected String getOnClickScript() {
return ParameterizedFakeAjaxEventBehavior.getOnClickScript(parent,
parameter, busySignal, getDecorator());
  }

  /**
   * @see
org.apache.wicket.markup.html.form.Button#onComponentTag(org.apache.wicket.markup.ComponentTag)
   */
  @Override
  protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
if (!busySignal) {
  tag.put(WebPageConstants.NOBUSY, true);
}
  }

  /**
   * Get decorator. Only {@link
IAjaxCallDecorator#decorateScript(CharSequence)}
   * is used here!
   *
   * @return {@link IAjaxCallDecorator}
   */
  protected IAjaxCallDecorator getDecorator() {
return null;
  }
}


2015-01-10 7:47 GMT+02:00 Martin Makundi martin.maku...@koodaripalvelut.com
:


 Wicket 7.0.0 is about to be released so it's a bit late for ideas.


 =) Is there a board for ideas for next one?


 But what you describe sounds like what  wicketstuff-stateless project
 already provides.


 I looked at
 https://github.com/mafulafunk/wicketstuff-core/tree/master/jdk-1.6-parent/stateless-parent/stateless/src/main/java/org/wicketstuff/stateless

 It is not quite the same what I am discussing. I mean that if you call
 page.removeAll() and execute the event, it would still work.

 We have implemented things like:


 /**
  *
  * Listener that collects fake events.
  *
  */
 public class FakeEventListener implements IListener {

   private static final MetaDataKeyFakeEventListener DATA_KEY = new
 MetaDataKeyFakeEventListener() {
 private static final long serialVersionUID = 1L;
   };

   private ArrayListString scripts = new ArrayListString();

   /**
* Constructor
*
*/
   private FakeEventListener() {
   }

   /**
* @see
 org.apache.wicket.ajax.AjaxRequestTarget.IListener#onBeforeRespond(java.util.Map,
*  org.apache.wicket.ajax.AjaxRequestTarget)
*/
   @Override
   public void onBeforeRespond(MapString, Component map,
 AjaxRequestTarget target) {
 // do nothing
   }

   /**
* @see
 org.apache.wicket.ajax.AjaxRequestTarget.IListener#onAfterRespond(java.util.Map,
*  org.apache.wicket.ajax.AjaxRequestTarget.IJavascriptResponse)
*/
   @Override
   public void onAfterRespond(MapString, Component map,
 IJavascriptResponse response) {
 StringBuilder builder = new StringBuilder();
 builder.append(var fakeev_inin = function(event) {);
 builder.append(if( typeof Tustor == 'undefined' || typeof
 Tustor.Events == 'undefined') { setTimeout(fakeev_inin, 10); } else {);
 for (String parentMarkupId : scripts) {
   builder.append(Tustor.Events.addFakeEventsClassName('.FACB);
   builder.append(index(parentMarkupId));
   builder.append(', ');
   builder.append(parentMarkupId);
   builder.append('););
 }
 builder.append(}};);
 builder.append($(document).ready(function(){fakeev_inin();}););
 response.addJavascript(builder.toString());
 RequestCycle.get().setMetaData(DATA_KEY, null);
   }

   /**
* Adds script;
*
* @param parentMarkupId
*
*/
   public void addScript(String parentMarkupId) {
 if(!scripts.contains(parentMarkupId)) {
   scripts.add

Re: Wikipedia comparison of frameworks: wicket is not MVC?

[Martin Makundi]

One can build a controller to manage all the onConfigure(xx) but the wicket
framework does not provide a controller so basically it's left for the
developer.

**
Martin

2014-11-02 17:52 GMT+02:00 Martijn Dashorst martijn.dasho...@gmail.com:

 On Sun, Nov 2, 2014 at 4:37 PM, andrea del bene an.delb...@gmail.com
 wrote:
  I don't even get why we find active record pattern for Grails...BTW,
  strictly speaking Wicket has no controller part so we might say no for
  MVC. In any case anything would be better than the current description :)

 We have: the component. It acts as both the controller and the view,
 so we are a Model2 framework!

 Or else we could say the RequestCycle is the controller but I think
 that is a stretch...

 Martijn

Re: Method chaining

[Martin Makundi]

Java should natively chain all void instance methods...

**
Martin


2014-01-31 Sven Meier s...@meiers.net

 I don't think it makes sense here:
 In all of Wicket's code there's a single place only, where two metaData
 entries are set consecutively.

 Sven


 On 01/31/2014 03:08 PM, Martin Grigorov wrote:

 Hi,

 What others think about https://issues.apache.org/jira/browse/WICKET-5459?
 Should Wicket use return this pattern where makes sense instead of
 'void'
 return type ?

 One problem that I see is with:
 MyPage.doSomething() will/may return some base type of MyPage.
 I remember some trink for Java to make this simpler but AFAIR it involved
 some longer generics signature for the class that use it.



 Martin Grigorov
 Wicket Training and Consulting

Re: wicket job opportunity, we are hiring

[Martin Makundi]

Why not stretch your hours Cedric, and have day off in your country ;)

2012/6/6 Cedric Gatay gata...@gmail.com:
 Hi Igor,
 this is an interesting opportunity, too bad it is time zone limited. I hope
 you'll find somebody.


 __
 Cedric Gatay
 http://www.bloggure.info | http://cedric.gatay.fr |
 @Cedric_Gatayhttp://twitter.com/Cedric_Gatay


 On Tue, Jun 5, 2012 at 10:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 the company i work for ( 42lines.net ) is growing and we are looking
 for a few good devs.

 about our approach:

 * we are a distributed company with employees based predominantly in
 the usa, there are 27 of us now
 * everyone telecommutes either from home or a coworking space of your
 choice (paid for by the company)
 * we use a variation of agile methodology (daily scrums, iterations,
 peer code reviews, etc)

 tech stack:

 * wicket
 * jpa/hibernate/querydsl
 * cdi/weld
 * resteasy
 * jquery / jquery mobile

 what we want from you:

 * first and foremost you are smart and you know how to apply those
 smarts to writing code
 * you work on PST/EST +- 2 hours
 * you have a decent internet connection capable of skype (we can help
 you get one)
 * you understand (not just know) java and oop
 * you are comfortable in sql, hibernate, and wicket

 there is lots more info, including how to apply, available here:


 https://www.42lines.net/2012/05/29/now-hiring-2-new-java-engineers-and-2-new-qa-engineers/

 cheers,
 -igor

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Queueing components?

[Martin Makundi]

It was so difficult to get the feature approved we didn't want to slow
the process down by debating its name then.

But now might be a good time ;)

**
Martin

2012/4/11 Minas Manthos minas.mant...@gmail.com:
 Hi

 I know there is already a lot discussion about Component queueing
 (https://issues.apache.org/jira/browse/WICKET-3335).

 Maybe I'm the only one, but I'm feeling not so comfortable with the term
 'queue'. I know you had a lot to do than discuss about the term, but I had
 to write this before it's finished and released.

 For me a 'queue' has more to do with first-in-first-out-things and IMO it's
 suboptimal in this context...

 I suggest to name it 'put' instead of 'queue'. So, I put a component into a
 container.

 add(...) - adds a component (explicitely) into a container
 put(...) - puts a component into a container (to be used freely during
 rendering)

 It's only my point of view... Please don't get me wrong, I don't want to
 start a big discussion about this (maybe you just want to vote?). Anyway..
 if you think 'queue' is the right term for this, ok, for me it's not a
 problem.


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Queueing-components-tp4549759p4549759.html
 Sent from the Forum for Wicket Core developers mailing list archive at 
 Nabble.com.

Proposal for 1.4.x

[Martin Makundi]

Hi!

For debugging, in Component.java:

try {
  modelChanging();
  model.setObject(object);
  modelChanged();
} catch (Throwable t) {
  throw new RuntimeException(PageRelativePath:  +
getPageRelativePath(), t);
}


**
Martin

Re: Proposal for 1.4.x

[Martin Makundi]

Hi!

Sometimes there is an exception in model update (propertymodels, etc.)
and is hard to know which component caused the problem. This component
path will help to resolve which component was guilty.

**
Martin

2011/10/8 Martin Grigorov mgrigo...@apache.org:
 ?

 catching Throwable is not good, Exception is enough
 But can you give more details

 On Sat, Oct 8, 2011 at 10:06 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hi!

 For debugging, in Component.java:

    try {
      modelChanging();
      model.setObject(object);
      modelChanged();
    } catch (Throwable t) {
      throw new RuntimeException(PageRelativePath:  +
 getPageRelativePath(), t);
    }


 **
 Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

Hi!

I have noticed lots of document.body=null situations with domready in
IE, I am currently trying out the following fix to wicket-event.js:

var domReady = function() {
function onBodyLoadedSafely() {
if (document.body) {
if (window.loaded)
return;
window.loaded = true;

// invoke the handlers

Wicket.Event.fireDomReadyHandlers();
} else {

window.setTimeout(onBodyLoadedSafely, 100);
}
}

onBodyLoadedSafely();
}.bind(this);


Domready is postponed until document.body


**
Martin

Re: Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

This affects 1.4 also?


2011/9/30 Martin Grigorov mgrigo...@apache.org:
 Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery
 merged in Wicket.next this kind of problems will be much less

 This branch is work in progress.

 On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij
 emond.papega...@topicus.nl wrote:
 Even though we came up with the fix ourselves, it did not solve the problem
 for us in all cases. The fix for 4080 fixed one of our apps, but the other
 still is very broken. Someone with knowledge about domready in IE should
 really look at this. We've abandoned wicket's domready and now use WiQuery to
 pass all domready events to JQuery's $(document).ready(), which works fine.

 Best regards,
 Emond

 On Friday 30 September 2011 08:49:46 Martin Grigorov wrote:
 It seems there is an update for IE that broke the state ...
 See also https://issues.apache.org/jira/browse/WICKET-4080

 On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi

 martin.maku...@koodaripalvelut.com wrote:
  Hi!
 
  I have noticed lots of document.body=null situations with domready in
  IE, I am currently trying out the following fix to wicket-event.js:
 
                                 var domReady = function() {
                                     function onBodyLoadedSafely() {
                                         if (document.body) {
                                                         if (window.loaded)
                                                                 return;
                                                         window.loaded =
  true;
 
                                                         // invoke the
  handlers Wicket.Event.fireDomReadyHandlers(); } else {
 
   window.setTimeout(onBodyLoadedSafely, 100); }
                                     }
 
                                     onBodyLoadedSafely();
                                 }.bind(this);
 
 
  Domready is postponed until document.body
 
 
  **
  Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

Umh.. not 1.4.17? We are in 1.4.17.

2011/9/30 Martin Makundi martin.maku...@koodaripalvelut.com:
 This affects 1.4 also?


 2011/9/30 Martin Grigorov mgrigo...@apache.org:
 Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery
 merged in Wicket.next this kind of problems will be much less

 This branch is work in progress.

 On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij
 emond.papega...@topicus.nl wrote:
 Even though we came up with the fix ourselves, it did not solve the problem
 for us in all cases. The fix for 4080 fixed one of our apps, but the other
 still is very broken. Someone with knowledge about domready in IE should
 really look at this. We've abandoned wicket's domready and now use WiQuery 
 to
 pass all domready events to JQuery's $(document).ready(), which works fine.

 Best regards,
 Emond

 On Friday 30 September 2011 08:49:46 Martin Grigorov wrote:
 It seems there is an update for IE that broke the state ...
 See also https://issues.apache.org/jira/browse/WICKET-4080

 On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi

 martin.maku...@koodaripalvelut.com wrote:
  Hi!
 
  I have noticed lots of document.body=null situations with domready in
  IE, I am currently trying out the following fix to wicket-event.js:
 
                                 var domReady = function() {
                                     function onBodyLoadedSafely() {
                                         if (document.body) {
                                                         if (window.loaded)
                                                                 return;
                                                         window.loaded =
  true;
 
                                                         // invoke the
  handlers Wicket.Event.fireDomReadyHandlers(); } else {
 
   window.setTimeout(onBodyLoadedSafely, 100); }
                                     }
 
                                     onBodyLoadedSafely();
                                 }.bind(this);
 
 
  Domready is postponed until document.body
 
 
  **
  Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

The problem with qjuery domready is that it ALWAYS renders domready.
However, current wicket domready works such that for example in ajax
events it executes immediately. You can see the difference if you have
jquery skinned components, a huge delay if using jquery.domready in
general and quite fast if you use wicket domready.

Such built in logic could ofcourse be built into a new implementation
of the event.

**
Martin

2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
 This will not be applied before wicket.next. Until then, I think we should
 really reconsider the current domready implementation on IE. Perhaps, we can
 'borrow' JQuery's ready implementation for now?

 On Friday 30 September 2011 09:18:32 Martin Makundi wrote:
 Umh.. not 1.4.17? We are in 1.4.17.

 2011/9/30 Martin Makundi martin.maku...@koodaripalvelut.com:
  This affects 1.4 also?
 
  2011/9/30 Martin Grigorov mgrigo...@apache.org:
  Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery
  merged in Wicket.next this kind of problems will be much less
 
  This branch is work in progress.
 
  On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij
 
  emond.papega...@topicus.nl wrote:
  Even though we came up with the fix ourselves, it did not solve the
  problem for us in all cases. The fix for 4080 fixed one of our apps,
  but the other still is very broken. Someone with knowledge about
  domready in IE should really look at this. We've abandoned wicket's
  domready and now use WiQuery to pass all domready events to JQuery's
  $(document).ready(), which works fine.
 
  Best regards,
  Emond
 
  On Friday 30 September 2011 08:49:46 Martin Grigorov wrote:
  It seems there is an update for IE that broke the state ...
  See also https://issues.apache.org/jira/browse/WICKET-4080
 
  On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi
 
  martin.maku...@koodaripalvelut.com wrote:
   Hi!
  
   I have noticed lots of document.body=null situations with domready
   in IE, I am currently trying out the following fix to
   wicket-event.js:
  
                                  var domReady = function() {
                                      function onBodyLoadedSafely() {
                                          if (document.body) {
                                                          if
   (window.loaded) return; window.loaded = true;
  
                                                          // invoke the
   handlers Wicket.Event.fireDomReadyHandlers(); } else {
  
    window.setTimeout(onBodyLoadedSafely, 100); }
                                      }
  
                                      onBodyLoadedSafely();
                                  }.bind(this);
  
  
   Domready is postponed until document.body
  
  
   **
   Martin
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com

Re: Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

Yes but you don't want to code special cases for all your components
renderhead to detect if is ajax or not. Is better to always use same
smart method which knows how to handle ajax/non-ajax.

**
Martin

2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
 IMHO, you should not use any ready event in AJAX, you should just evaluate the
 statements after updating the DOM. AFAIC, this is what AjaxHeaderResponse does
 for calls to renderOnDomReadyJavaScript.

 On Friday 30 September 2011 09:30:58 Martin Makundi wrote:
 The problem with qjuery domready is that it ALWAYS renders domready.
 However, current wicket domready works such that for example in ajax
 events it executes immediately. You can see the difference if you have
 jquery skinned components, a huge delay if using jquery.domready in
 general and quite fast if you use wicket domready.

 Such built in logic could ofcourse be built into a new implementation
 of the event.

 **
 Martin

 2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
  This will not be applied before wicket.next. Until then, I think we
  should really reconsider the current domready implementation on IE.
  Perhaps, we can 'borrow' JQuery's ready implementation for now?
 
  On Friday 30 September 2011 09:18:32 Martin Makundi wrote:
  Umh.. not 1.4.17? We are in 1.4.17.
 
  2011/9/30 Martin Makundi martin.maku...@koodaripalvelut.com:
   This affects 1.4 also?
  
   2011/9/30 Martin Grigorov mgrigo...@apache.org:
   Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery
   merged in Wicket.next this kind of problems will be much less
  
   This branch is work in progress.
  
   On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij
  
   emond.papega...@topicus.nl wrote:
   Even though we came up with the fix ourselves, it did not solve the
   problem for us in all cases. The fix for 4080 fixed one of our apps,
   but the other still is very broken. Someone with knowledge about
   domready in IE should really look at this. We've abandoned wicket's
   domready and now use WiQuery to pass all domready events to JQuery's
   $(document).ready(), which works fine.
  
   Best regards,
   Emond
  
   On Friday 30 September 2011 08:49:46 Martin Grigorov wrote:
   It seems there is an update for IE that broke the state ...
   See also https://issues.apache.org/jira/browse/WICKET-4080
  
   On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi
  
   martin.maku...@koodaripalvelut.com wrote:
Hi!
   
I have noticed lots of document.body=null situations with
domready in IE, I am currently trying out the following fix to
wicket-event.js:
   
                               var domReady = function() {
                                   function onBodyLoadedSafely()
{ if (document.body) { if (window.loaded) return; window.loaded
= true;
   
                                                       // invoke
the handlers Wicket.Event.fireDomReadyHandlers(); } else {
   
 window.setTimeout(onBodyLoadedSafely, 100); }
                                   }
   
                                   onBodyLoadedSafely();
                               }.bind(this);
   
   
Domready is postponed until document.body
   
   
**
Martin
  
   --
   Martin Grigorov
   jWeekend
   Training, Consulting, Development
   http://jWeekend.com

Re: Wicket 1.4.17 wicket-event.js domready

[Martin Makundi]

2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
 In Wicket-1.5, this already is the case. So I guess, you'll have to upgrade...

Is same in 1.4 also. IE is the problem, not wicket ;]

**
Martin

 On Friday 30 September 2011 09:49:51 Martin Makundi wrote:
 Yes but you don't want to code special cases for all your components
 renderhead to detect if is ajax or not. Is better to always use same
 smart method which knows how to handle ajax/non-ajax.

 **
 Martin

 2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
  IMHO, you should not use any ready event in AJAX, you should just
  evaluate the statements after updating the DOM. AFAIC, this is what
  AjaxHeaderResponse does for calls to renderOnDomReadyJavaScript.
 
  On Friday 30 September 2011 09:30:58 Martin Makundi wrote:
  The problem with qjuery domready is that it ALWAYS renders domready.
  However, current wicket domready works such that for example in ajax
  events it executes immediately. You can see the difference if you have
  jquery skinned components, a huge delay if using jquery.domready in
  general and quite fast if you use wicket domready.
 
  Such built in logic could ofcourse be built into a new implementation
  of the event.
 
  **
  Martin
 
  2011/9/30 Emond Papegaaij emond.papega...@topicus.nl:
   This will not be applied before wicket.next. Until then, I think we
   should really reconsider the current domready implementation on IE.
   Perhaps, we can 'borrow' JQuery's ready implementation for now?
  
   On Friday 30 September 2011 09:18:32 Martin Makundi wrote:
   Umh.. not 1.4.17? We are in 1.4.17.
  
   2011/9/30 Martin Makundi martin.maku...@koodaripalvelut.com:
This affects 1.4 also?
   
2011/9/30 Martin Grigorov mgrigo...@apache.org:
Hopefully with https://github.com/martin-g/wicket/tree/ajax-jquery
merged in Wicket.next this kind of problems will be much less
   
This branch is work in progress.
   
On Fri, Sep 30, 2011 at 8:56 AM, Emond Papegaaij
   
emond.papega...@topicus.nl wrote:
Even though we came up with the fix ourselves, it did not solve
the problem for us in all cases. The fix for 4080 fixed one of
our apps, but the other still is very broken. Someone with
knowledge about domready in IE should really look at this. We've
abandoned wicket's domready and now use WiQuery to pass all
domready events to JQuery's $(document).ready(), which works
fine.
   
Best regards,
Emond
   
On Friday 30 September 2011 08:49:46 Martin Grigorov wrote:
It seems there is an update for IE that broke the state ...
See also https://issues.apache.org/jira/browse/WICKET-4080
   
On Fri, Sep 30, 2011 at 8:27 AM, Martin Makundi
   
martin.maku...@koodaripalvelut.com wrote:
 Hi!

 I have noticed lots of document.body=null situations with
 domready in IE, I am currently trying out the following fix to
 wicket-event.js:

                                var domReady = function() {
                                    function
 onBodyLoadedSafely() { if (document.body) { if
 (window.loaded) return; window.loaded = true;

                                                        //
 invoke the handlers Wicket.Event.fireDomReadyHandlers(); }
 else {

  window.setTimeout(onBodyLoadedSafely, 100); }
                                    }

                                    onBodyLoadedSafely();
                                }.bind(this);


 Domready is postponed until document.body


 **
 Martin
   
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

Self type

[Martin Makundi]

Hi!

Is wicket using self type yet for methods like add(cc) {...; return this; } ?

http://calliopesounds.blogspot.com/2010/11/having-java-generic-class-return-type.html

**
Martin

Re: Self type

[Martin Makundi]

Oh, java 7 is nicer?

http://blog.joda.org/2007/08/java-7-self-types_1953.html

2011/8/30 richard emberson richard.ember...@gmail.com:
 For many months the Scala port of Wicket 1.5 has used self type
 return values (this.type) where appropriate; more than 10 methods
 in Component, more than 5 in MarkupContainer, etc. with all
 tests passing and some code simplification (or, at least, the
 removal of some casts). Ought to work in Java also.

 Richard

 On 08/29/2011 06:52 PM, Martin Makundi wrote:

 Hi!

 Is wicket using self type yet for methods like add(cc) {...; return this;
 } ?


 http://calliopesounds.blogspot.com/2010/11/having-java-generic-class-return-type.html

 **
 Martin


 --
 Quis custodiet ipsos custodes

Possibility of nullpointer in wicket-ajax.js

[Martin Makundi]

Hi!

Wicket-ajax 1.4 suffers nullpointer in Chrome:

// go through newly added elements and try to find javascripts that
// need to be executed
while (element != next) {
try {
Wicket.Head.addJavascripts(element);
} catch (ignore) {
}
element = element.nextSibling;
wicket-ajax.js:343Uncaught TypeError: Cannot read property 'nextSibling' of null
}


Stranegly this nullpointer occurs only in Chrome in some very rare
situations (completely unrelated dom differences seem to make the
difference of having or not having a nullpointer here - very
difficult to reproduce in general).

**
Martin

Re: Possibility of nullpointer in wicket-ajax.js

[Martin Makundi]

Oh, I so embrace Change ...

**
Martin

2011/8/12 Martin Grigorov mgrigo...@apache.org:
 It is fixed in 1.4.18.
 It was caused by a change in Chrome (and later WebKit) behavior

 On Fri, Aug 12, 2011 at 11:48 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hi!

 Wicket-ajax 1.4 suffers nullpointer in Chrome:

 // go through newly added elements and try to find javascripts that
    // need to be executed
    while (element != next) {
        try {
            Wicket.Head.addJavascripts(element);
        } catch (ignore) {
        }
        element = element.nextSibling;
 wicket-ajax.js:343Uncaught TypeError: Cannot read property 'nextSibling' of 
 null
    }


 Stranegly this nullpointer occurs only in Chrome in some very rare
 situations (completely unrelated dom differences seem to make the
 difference of having or not having a nullpointer here - very
 difficult to reproduce in general).

 **
 Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Double invocation in Localizer

[Martin Makundi]

Hmm.. I don't see that. I see in both they are executed when (value != null)

Also if I step through with debugger, it invokes twice
substitutePropertyExpressions

**
Martin

2011/7/27 Martin Grigorov mgrigo...@apache.org:
 If you read carefully the code you'll see that the calls are in if/else.
 The first call is called only if the returned 'value' is non-null. The
 second is called only if the value was null and defaultValue is used.

 On Wed, Jul 27, 2011 at 5:30 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hi!

 In wicket 1.4.17 it seems like there is deouble invocation of
 substitutePropertyExpressions, is this intentional?

    public String getString(final String key, final Component component,
 final IModel? model,
        final String defaultValue) throws MissingResourceException
    {
       ...
        String value = getStringIgnoreSettings(key, component, model, null);
 --- calls substitutePropertyExpressions(component, value, model);
       ...
          if (value != null)
        {
            return substitutePropertyExpressions(component, value, model);
        }
       ...
    {

 and inside getStringIgnoreSettings:

    public String getStringIgnoreSettings(final String key, final Component
 component,
        final IModel? model, final String defaultValue)
    {
       ...
          if (value != null)
        {
            return substitutePropertyExpressions(component, value, model);
        }
       ...
    {


 Seems redundant and might have some performance considerations?

 **
 Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Double invocation in Localizer

[Martin Makundi]

 My observations were about 1.5.
 You are right about 1.4.
 One more proof that 1.5 is better :-)

Anybody use 1.5 in production after refactoring from 1.4 ?

**
Martin

 On Wed, Jul 27, 2011 at 9:26 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hmm.. I don't see that. I see in both they are executed when (value != null)

 Also if I step through with debugger, it invokes twice
 substitutePropertyExpressions

 **
 Martin

 2011/7/27 Martin Grigorov mgrigo...@apache.org:
 If you read carefully the code you'll see that the calls are in if/else.
 The first call is called only if the returned 'value' is non-null. The
 second is called only if the value was null and defaultValue is used.

 On Wed, Jul 27, 2011 at 5:30 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hi!

 In wicket 1.4.17 it seems like there is deouble invocation of
 substitutePropertyExpressions, is this intentional?

    public String getString(final String key, final Component component,
 final IModel? model,
        final String defaultValue) throws MissingResourceException
    {
       ...
        String value = getStringIgnoreSettings(key, component, model, null);
 --- calls substitutePropertyExpressions(component, value, model);
       ...
          if (value != null)
        {
            return substitutePropertyExpressions(component, value, model);
        }
       ...
    {

 and inside getStringIgnoreSettings:

    public String getStringIgnoreSettings(final String key, final Component
 component,
        final IModel? model, final String defaultValue)
    {
       ...
          if (value != null)
        {
            return substitutePropertyExpressions(component, value, model);
        }
       ...
    {


 Seems redundant and might have some performance considerations?

 **
 Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

onBeforeRender called twice

[Martin Makundi]

Hi!

Is it ok that onBeforeRender is called twice (1.4.9):

1.
Server.handle(HttpConnection) line: 326 
HttpConnection.handleRequest() line: 534
HttpConnection$RequestHandler.headerComplete() line: 864
HttpParser.parseNext() line: 539


2.
Server.handle(HttpConnection) line: 326 
HttpConnection.handleRequest() line: 534
HttpConnection$RequestHandler.content(Buffer) line: 879 
HttpParser.parseNext() line: 747
HttpParser.parseAvailable() line: 218   
HttpConnection.handle() line: 404   


Is this normal ?

**
Martin

MinimumValidator should have model?

[Martin Makundi]

Hi!

MinimumValidator should have model so that boundaries must be
initialized only for changed form components?

**
Martin

Re: MinimumValidator should have model?

[Martin Makundi]

Yes, ofcourse, but it seems weird that the built-in wicket validators
don't follow the IModel pattern.

**
Martin

2011/4/22 Martin Grigorov mgrigo...@apache.org:
 I don't understand the question but you can create your own IValidator
 that do exactly what you need.

 On Fri, Apr 22, 2011 at 11:52 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 Hi!

 MinimumValidator should have model so that boundaries must be
 initialized only for changed form components?

 **
 Martin




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: How to streamline ajax page region toggle

[Martin Makundi]

 the childComponent's
  visibility before it renders the Enclosure. At the end that's the
  whole idea of Enclosure. You never explicity change the Enclosure's
  visibility. You always (with and without ajax) change the visibility
  of the child component. Do I misunderstand something?
 
  b) you prefer a wicket:enclosure attribute over a wicket:enclosure tag
  you prefer div wicket:enclosure=child:label1 over
  wicket:enclosure child=label1
  Neither requires any java code. Neither is really longer or shorter
  than the other. Neither requires more or less boilerplate. It seems to
  me a matter of personal preference. That's up to the community what
  you like. We can have either or both. I'm personally more in favour of
  the tag, but that's of course only my opinion.

 the problem with the tag is that it is not rendered into the markup so
 cannot be targetted via ajax.

 -igor

 
  - Juergen
 
 
  On Tue, Feb 8, 2011 at 7:34 AM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
  i will try to look over it in the few coming days and give you some
 feedback.
 
  -igor
 
  On Mon, Feb 7, 2011 at 3:43 AM, Joo Hama joonas.hamalai...@gmail.com
 wrote:
  Thanks Igor and Jeremy,
 
  I managed to resolve these issues and committed a patch to JIRA:
 
  https://issues.apache.org/jira/browse/WICKET-3422
 
  It introduces an inline Enclosure defined as an attribute of a
  html tag, and a listener to find the right inline Enclosures at the
  time of Ajax request handling. It seems to work well with the existing
  wicket
  code base, and all tests are green. What do you guys think? Is it
 suitable
  material to commit to wicket?
 
  - Joonas
  https://issues.apache.org/jira/browse/WICKET-3422
 
  On Fri, Jan 21, 2011 at 8:41 PM, Joo Hama joonas.hamalai...@gmail.com
 wrote:
 
 
  The EnclosureResolver... container.autoAdd seems to be invoked only in
 the
  parsing
  phase of the original request, whereas the onBeforeRender is invoked
 during
  handling
  of the AjaxRequest (when the listener is attached to the
  AjaxRequestTarget).
 
  I found out that the Enclosure is not a child of a Page, thus making
 it
  quite elusive
  to get hold of in the onBeforeRespond event. I even attempted to
  read MarkupStream,
  and indeed found the tag there. (source below) However, in order to
 add it
  to the requestTarget, we
  need to get hold of the component. I tried to read the path of the tag
 in
  the document
  using ComponentTag.getPath(), but it was null. This is where i hit
 brick
  wall.
 
  Is it possible to get hold of the Enclosure component with only
  the WicketTag from the
  MarkupStream as reference? If not, i think this approach might not be
  viable.
 
 
  // Override of the application class method newAjaxRequestTarget,
 trying to
  find enclosures that have
  // the child id of a component
  // in the ajaxTarget:
  //---
  @Override
  public AjaxRequestTarget newAjaxRequestTarget(Page page) {
      AjaxRequestTarget target = super.newAjaxRequestTarget(page);
      target.addListener(new AjaxRequestTarget.IListener() {
 
          public void onBeforeRespond(MapString, Component map,
   AjaxRequestTarget target) { ListString ids = new
 ArrayListString();
  Page page = null; // first read all the component id:s from the target
 for
  (Component component : map.values()) { page = component.getPage();
  ids.add(component.getId()); } // then traverse the markupStream to
 find
  enclosureTags if (page != null) { MarkupStream stream =
  page.getMarkupStream(); stream.setCurrentIndex(0); while
 (stream.hasMore())
  { stream.skipRawMarkup(); if (stream.hasMore()) { WicketTag tag = new
  WicketTag(stream.getTag()); if (tag.isEnclosureTag()) { // Try to
 match the
  enclosureTag:s child id to the ids in the target String childId =
  tag.getAttribute(child); if (childId != null) { String[] parts =
  childId.split(:); childId = parts[parts.length - 1]; for (String id
 : ids)
  { if (id.equals(childId)) { System.err .println(Found enclosure  +
  tag.getId() +  at path: + tag.getPath() + , who's child is targeted
 Id=
  + childId); } } } } stream.next(); } } } }
  public void onAfterRespond(MapString, Component map,
 IJavascriptResponse
  response) { System.err.println(onAfterRespond); } }); return target;
 }
  //-
 
 
  On Fri, Jan 21, 2011 at 3:58 PM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  Hi!
 
  EnclosureResolvercontainer.autoAdd is invoked at render phase?
  Would it be necessary to hook into a different event (instead of
  onBeforeRender) or could it be pre-sniffed at onBeforeRender?
 
  **
  Martin
 
  2011/1/21 Joo Hama joonas.hamalai...@gmail.com:
   I tested this idea by adding the code below to my web application
   object. Problem was though,
   that when viewing the variables in debugger, the enclosure object
 didn't
   seem to be included in
   the tree of the parent objects. It was as if the enclosure was
 invisible
  to
   them. Perhaps because
   Enclosure

Re: WicketTester#assertInvisible

[Martin Makundi]

This is a fundamental dilemma ;) Also on implementation side somebody
may implement:

1)
isvisible() {
 return super.isvisible()  businesslogic.isvisible();
}

or simply

2)
isvisible() {
 return businesslogic.isvisible();
}


So if 2) is allowed and recommended, then isvisible is really only
businesslogic test instead of real visibilty check.


**
Martin

2011/2/13 Jeremy Thomerson jer...@wickettraining.com:
 I just ran across this nuance this week  If you have this:

 wicket:enclosure child=comp1
  div wicket:id=comp1/div
  div wicket:id=comp2/div
 /wicket:enclosure

 Now, say comp1 is invisible, so the whole enclosure is invisible.  Now, in
 WicketTester, if you test assertInvisible(comp2), it will fail because
 technically comp2 *is* visible itself, but it's not really visible because
 its parent is not visible.

 So, I want to fix this.  My question for the group is, which should I do:

 1 - change assertInvisible to test that it is truly visible (i.e., in
 hierarchy)?

 2 - add a new method, assertInvisibleInHierarchy that tests for actual
 visibility and add to the javadoc for assertInvisible that it only tests the
 actual component's visibility, and not its true visibility (as in, in the
 hierarchy)?

 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: WicketTester#assertInvisible

[Martin Makundi]

 I haven't looked at the exact implementation of
 WicketTester, but I think we should change the logic to pass assertInvisible
 if the component's isVisible method returns true, but some parent of the
 component (an enclosure, etc) is not visible, since in all reality, the
 component is then also invisible.

It is like that already:

public Result isVisible(String path)
{
Component component = getLastRenderedPage().get(path);
if (component == null)
{
fail(path: ' + path + ' does no exist for page: 
+ 
Classes.simpleName(getLastRenderedPage().getClass()));
}

return isTrue(component ' + path + ' is not visible,
component.isVisibleInHierarchy());
}



 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: How to streamline ajax page region toggle

[Martin Makundi]

Hi!

EnclosureResolvercontainer.autoAdd is invoked at render phase?
Would it be necessary to hook into a different event (instead of
onBeforeRender) or could it be pre-sniffed at onBeforeRender?

**
Martin

2011/1/21 Joo Hama joonas.hamalai...@gmail.com:
 I tested this idea by adding the code below to my web application
 object. Problem was though,
 that when viewing the variables in debugger, the enclosure object didn't
 seem to be included in
 the tree of the parent objects. It was as if the enclosure was invisible to
 them. Perhaps because
 Enclosure is a transparent resolver?

 object tree in my application:

 - page
  - enclosure
     - div (the parent of this was shown to be page, not the enclosure)


 Code:
 //-
 @Override public AjaxRequestTarget newAjaxRequestTarget(Page page) {
 AjaxRequestTarget target = super.newAjaxRequestTarget(page);
 target.addListener(new AjaxRequestTarget.IListener() { public void
 onBeforeRespond(MapString, Component map, AjaxRequestTarget target) {
 for(Component component : map.values()) { Enclosure parentEnclosure =
 component.findParent(Enclosure.class); if (parentEnclosure != null) {
 Enclosure topParent = new Enclosure(DUMMY, DUMMY); while (topParent !=
 null) { topParent = parentEnclosure.findParent(Enclosure.class); if
 (topParent != null) { parentEnclosure = topParent; } }
 target.addComponent(parentEnclosure); } } } public void
 onAfterRespond(MapString, Component map, IJavascriptResponse response) {}
 }); return target; };
 //---


 On Fri, Jan 21, 2011 at 3:07 AM, Jeremy Thomerson jer...@wickettraining.com
 wrote:

 On Thu, Jan 20, 2011 at 1:51 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:

  interesting idea. i think this would require a bit of a trick.
 
  a) modify enclosure tag handler to accept an attribute instead of a tag
  b) modify enclosure tag handler to add a bit of metadata to the
  component marking that it belongs to an enclosure
  c) add a ajaxrequesttarget.listener to the request target that checks
  for this bit of metadata and adds the enclosure container to the ajax
  request target.
 
  not sure how feasible this all is because the enclosure container is
  an auto component. but, you are welcome to tinker around.
 
  -igor


 I, too, like the idea.  Couldn't it be simpler?  Couldn't he:

 1: Override newAjaxRequestTarget in WebApplication
 2: When he creates an ART, add a listener to it.
 3: In the listener, in onBeforeRespond, do this:

 for(Component component : map.values()) {
    Enclosure parentEnclosure = component.findParent(Enclosure.class);
    while (parentEnclosure != null) {
        Enclosure topParent = parentEnclosure.findParent(Enclosure.class);
        if (topParent != null) {
            parentEnclosure = topParent;
        }
    }
    if (parentEnclosure != null) {
        addComponent(parentEnclosure);
    }
 }



 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: Scala-Wicket Help and Advice

[Martin Makundi]

The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).

Scala maybe needs a bit more syntactical canonicity?

**
Martin

2011/1/19 richard emberson richard.ember...@gmail.com:
 Yea,

 I have consistently advocated using Scala with strong coding
 standards - standards that are actually believed in and enforced.
 I have referred to it as OO Scala, Scala which is strong on the
 Java-like Object-Oriented features plus functional programming
 in-the-small, but refrains from using functional programming
 in-the-large, many of Scala's functional goodies and advanced
 type capabilities (and if any of these really have to be used, they
 should be approved by the group and be documented in detail).

 The reasons for Scala and using it with limitation are:
  Scala is a better Java and
  The use of Scala's advanced features must be controlled so that
  code is understandable, maintainable and, most importantly, so that
  one can access the existing programmer labor pool and not have to
  limit one self to the very small number of FP programmers out there.

 Those who advocate the use of Scala's advanced features on large
 projects are really advocating that Scala be only a niche language.

 Richard

 On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:

 Hey mate,

 I code Java for my day job, and write my fun code in Scala. I just love
 the
 flexibility of Scala combined with the power to use all my existing Java
 libraries. That said,
 I don't see Scala overcoming Java anytime soon because it offers
 developers
 _too much_ freedom. I had a real bad time using
 http://dispatch.databinder.net for a project, because it fully utilized a
 lot of Scala features to offer a really shit API. Java makes everyone
 conform to a base level while preventing soaring, and it's a base level
 that's sane. And when it comes to writing  business code, as in Code that
 makes money, Scala's freedom doesn't offer overly much compared to Java's
 enforced conformity.

 Don't get me wrong, I3 Scala, but while half of me wants to use it at
 work, the other half is terrified of what the Java developers who write
 Spring code like this:

 bean id=something class=java.lang.String
     constructor-arg index=0
         value${someProperty}/value
     /constructor-arg
 /bean

 Would do with the power of Scala at their finger tips. (PS, that's real
 Spring code that I saw (and refactored) today.)

 On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
 richard.ember...@gmail.com  wrote:

 I originally mentioned the Kuhn book in the context of the politics of
 change.  Altering the focus, you brought up *the truth* as the view
 held by those resisting change, which I believe is not the larger
 insight to be gained from his book.  It is still my contention that my
 original interpretation is valid; Scala faces resistance to change and
 the structure of that resistance, maps into those structures
 identified by Kuhn.

 Using a term you earlier used, I think it would be naive to believe
 that entrenched business forces will stop the emergence of a new,
 major development language. Such forces were aligned against C, C++
 and Java, but the forces were overcome.  In each case, rational
 examination of the languages revealed advantages as well as
 non-rational forces, such as Sun's marketing and glitter in the case
 of Java, strengthening the prospects of the language's adaption. I
 hope we can both agree that change will come.

 But, I do not believe the change will be revolutionary but, rather,
 evolutionary. A language that evolves from an existing ecosystem has a
 much greater likelihood of becoming significant than a green field
 language.

 I paint and sculpt as well as do mathematics and physics and, for me,
 language selection is far closer to math and physics than to the play
 of colors or shape and form. I, thus, do not agree that choosing a
 programming language is an exercise in artistry, but rather, its a
 more rational process.  And, if beauty is involved, then it is
 scientific beauty and not artistic beauty.  Are you Picasso? Maybe
 even Mondrian? Hopefully, not Pollock.

 Concerning the languages you listed as the way forward, an important
 criteria must be: where are the programmers coming from?  One can wait
 for a new generation or one can see if any existing programmers will
 migrate from their current language to a new language.  Some language
 usages from the web:
    Java         18%
    C            16%
    C++           9%
    Python        6%
    C#            6%
    Objective-C   3%
    Ruby          2%
    Lisp          1%
    Scheme       ~0.5%
    Haskell      ~0.3%
    Scala        ~0.3%
    Eiffel0.1%
    Clojure      ~0.0%

 So, where might future 

Re: Scala-Wicket Help and Advice

[Martin Makundi]

Yeah.. scala is like javazcribl ;)

2011/1/19 Gustavo Hexsel ghex...@gmail.com:
  Flexible syntax is a big part of it, but combined with operator override,
 it's a potential hole for understanding.
  They will never officially do that because one big use-case for scala is
 DSLs, in which this is an advantage (and the main scala team just got a
 reasonably large funding from a group that is interested in using Scala as
 DSLs).

  I'm with Richard, only strict coding standards will move Scala into
 mainstream (ok ok, there are a FEW mainstream projects, but I mean
 MAINmainstream).  I'm not sure why it was never officially proposed yet...

    []s Gus


 On Wed, Jan 19, 2011 at 7:22 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 The only thing that bugs me about scala is its flexibility of
 accepting different kind of notation. It's that what was the
 downfall of html: making complilers flexible to allow various human
 input and as end result none of the browsers work correctly because
 the truth is only in the eye of the beholder (or creator only, in
 this case).

 Scala maybe needs a bit more syntactical canonicity?

 **
 Martin

 2011/1/19 richard emberson richard.ember...@gmail.com:
  Yea,
 
  I have consistently advocated using Scala with strong coding
  standards - standards that are actually believed in and enforced.
  I have referred to it as OO Scala, Scala which is strong on the
  Java-like Object-Oriented features plus functional programming
  in-the-small, but refrains from using functional programming
  in-the-large, many of Scala's functional goodies and advanced
  type capabilities (and if any of these really have to be used, they
  should be approved by the group and be documented in detail).
 
  The reasons for Scala and using it with limitation are:
   Scala is a better Java and
   The use of Scala's advanced features must be controlled so that
   code is understandable, maintainable and, most importantly, so that
   one can access the existing programmer labor pool and not have to
   limit one self to the very small number of FP programmers out there.
 
  Those who advocate the use of Scala's advanced features on large
  projects are really advocating that Scala be only a niche language.
 
  Richard
 
  On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:
 
  Hey mate,
 
  I code Java for my day job, and write my fun code in Scala. I just love
  the
  flexibility of Scala combined with the power to use all my existing Java
  libraries. That said,
  I don't see Scala overcoming Java anytime soon because it offers
  developers
  _too much_ freedom. I had a real bad time using
  http://dispatch.databinder.net for a project, because it fully utilized
 a
  lot of Scala features to offer a really shit API. Java makes everyone
  conform to a base level while preventing soaring, and it's a base level
  that's sane. And when it comes to writing  business code, as in Code
 that
  makes money, Scala's freedom doesn't offer overly much compared to
 Java's
  enforced conformity.
 
  Don't get me wrong, I3 Scala, but while half of me wants to use it at
  work, the other half is terrified of what the Java developers who write
  Spring code like this:
 
  bean id=something class=java.lang.String
      constructor-arg index=0
          value${someProperty}/value
      /constructor-arg
  /bean
 
  Would do with the power of Scala at their finger tips. (PS, that's real
  Spring code that I saw (and refactored) today.)
 
  On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
  richard.ember...@gmail.com  wrote:
 
  I originally mentioned the Kuhn book in the context of the politics of
  change.  Altering the focus, you brought up *the truth* as the view
  held by those resisting change, which I believe is not the larger
  insight to be gained from his book.  It is still my contention that my
  original interpretation is valid; Scala faces resistance to change and
  the structure of that resistance, maps into those structures
  identified by Kuhn.
 
  Using a term you earlier used, I think it would be naive to believe
  that entrenched business forces will stop the emergence of a new,
  major development language. Such forces were aligned against C, C++
  and Java, but the forces were overcome.  In each case, rational
  examination of the languages revealed advantages as well as
  non-rational forces, such as Sun's marketing and glitter in the case
  of Java, strengthening the prospects of the language's adaption. I
  hope we can both agree that change will come.
 
  But, I do not believe the change will be revolutionary but, rather,
  evolutionary. A language that evolves from an existing ecosystem has a
  much greater likelihood of becoming significant than a green field
  language.
 
  I paint and sculpt as well as do mathematics and physics and, for me,
  language selection is far closer to math and physics than to the play
  of colors or shape and form. I, thus, do not agree that choosing

Re: Scala-Wicket Help and Advice

[Martin Makundi]

What about rewriting wicket into most wonderful tight functional scala style?

def : webserver {
   homepage,
   logoutpage,
   onlinestore,
}

...

;)

**
Martin

2011/1/19 James Carman ja...@carmanconsulting.com:
 I believe this conversation has gone enough off-course that it no
 longer belongs on this mailing list.  We're not discussing anything
 related to Wicket anymore.

 On Wed, Jan 19, 2011 at 11:57 AM, richard emberson
 richard.ember...@gmail.com wrote:


 On 01/19/2011 07:22 AM, Martin Makundi wrote:

 The only thing that bugs me about scala is its flexibility of
 accepting different kind of notation. It's that what was the
 downfall of html: making complilers flexible to allow various human
 input and as end result none of the browsers work correctly because
 the truth is only in the eye of the beholder (or creator only, in
 this case).

 I guess concerning HTML, I would say that it did not have a good
 enough spec soon enough and, of course, MS did whatever they wanted
 anyway.
 Scala has a very, very detailed spec (do not try to learn the
 language by reading the spec first).
 Scala also has the incredible advantage that the Scala team
 can make changes that are not backward compatible, which is to
 say, Scala has had a long gestation period.
 This advantage was particularly useful in going from the 2.7 to 2.8
 releases where the whole collection framework was redone. They are
 finding out what works best and folding those changes back into the
 language.  This will slow down with time (I expect the collection
 re-write is the last super big change).


 Scala maybe needs a bit more syntactical canonicity?

 I agree, languages have multiple ways of doing things:
    while-loop and for-loops
    i++ vs i += 1 vs i = i + 1 (Scala does not support i++)

 First, Scala is both OO and FP, so there are generally a
 couple of approaches - one that looks like Java and one that
 is more pipelined, data flowing through functions.

 So, it is true that Scala allows one to be creative!?.
 Some of this comes from the vastly richer set of capabilities
 associated with the collection classes. In Java one has
 Iterator while in Scala there is a whole lot of extra
 standard methods.

 Just yesterday while working on my NIST RBAC code, I had to
 decide how to check access rights in a test class:
  Does a Session have a given Permission, where
  Roles are in a Set and RolesToPerm is a Map from Role to Permission:

  def checkAccess(session: Session, perm: Permission): Boolean = {
 // version 0, very Java-like, never considered
    for (role - session.getRoles) {
      val pOp = roleToPerms.get(role)
      if (permOp.isDefined)
        if (permOp.get == perm) return true
    }
    false

 // or version 1, handling Option the Scala-way
    for (role - session.getRoles) {
      roleToPerms.get(role) match {
        case Some(p) = if (p == perm) return true
        case None = // ignore
      }
    }
    false

 // or version 2, rather more functional
    sesson.getRoles.foldLeft(false) { _ || roleToPerms.get(_).getOrElse(null)
 == perm }
  }

 The first two versions are not too hard to understand, but the last
 one, unless you know what foldLeft does, is, I imagine, opaque to most
 Java programmers.
 [foldLeft sets the result value with an initial value, false, and
 then iterates over the values of the container, roles, performing
 the operation, ||, creating a new result value on each iteration
 where the first _ is the current result value and the second _ is
 the value from the container.  getOrElse returns the value looked up
 from roleToPerms and, if it does not exist, returns null. Lastly,
 the iteration stops when the first true value, == perm is true;
 the normal || shortcutting.]
 That said, I consider the code to be functional
 programming in-the-small, a single line of code and, ultimately, more
 understandable (and more maintainable) than either of the proceeding
 versions.  [There maybe a better way to pipeline the evaluation, this
 is just what I did.]

 I have very mixed feelings about DSLs. If every programmer in your
 project creates their own DSLs for their own section or, even worse,
 per class, then DSLs are very bad; less understandable code, a
 maintenance problem and a barrier to getting new hires up to speed.
 On the other hand, if a project controls the use of DSLs and they
 are well documented, they could (not will be, but could) be a boon
 rather than a bust.


 **
 Martin

 2011/1/19 richard embersonrichard.ember...@gmail.com:

 Yea,

 I have consistently advocated using Scala with strong coding
 standards - standards that are actually believed in and enforced.
 I have referred to it as OO Scala, Scala which is strong on the
 Java-like Object-Oriented features plus functional programming
 in-the-small, but refrains from using functional programming
 in-the-large, many of Scala's functional goodies and advanced
 type capabilities (and if any of these really have to be used, they
 should

Re: Scala-Wicket Help and Advice

[Martin Makundi]

Why people use C++ to facilitate making business a mess?

**
Martin

2011/1/19 Liam Clarke-Hutchinson l...@steelsky.co.nz:
 Hey mate,

 I code Java for my day job, and write my fun code in Scala. I just love the
 flexibility of Scala combined with the power to use all my existing Java
 libraries. That said,
 I don't see Scala overcoming Java anytime soon because it offers developers
 _too much_ freedom. I had a real bad time using
 http://dispatch.databinder.net for a project, because it fully utilized a
 lot of Scala features to offer a really shit API. Java makes everyone
 conform to a base level while preventing soaring, and it's a base level
 that's sane. And when it comes to writing  business code, as in Code that
 makes money, Scala's freedom doesn't offer overly much compared to Java's
 enforced conformity.

 Don't get me wrong, I 3 Scala, but while half of me wants to use it at
 work, the other half is terrified of what the Java developers who write
 Spring code like this:

 bean id=something class=java.lang.String
    constructor-arg index=0
        value${someProperty}/value
    /constructor-arg
 /bean

 Would do with the power of Scala at their finger tips. (PS, that's real
 Spring code that I saw (and refactored) today.)

 On Tue, Jan 18, 2011 at 5:33 PM, richard emberson 
 richard.ember...@gmail.com wrote:

 I originally mentioned the Kuhn book in the context of the politics of
 change.  Altering the focus, you brought up *the truth* as the view
 held by those resisting change, which I believe is not the larger
 insight to be gained from his book.  It is still my contention that my
 original interpretation is valid; Scala faces resistance to change and
 the structure of that resistance, maps into those structures
 identified by Kuhn.

 Using a term you earlier used, I think it would be naive to believe
 that entrenched business forces will stop the emergence of a new,
 major development language. Such forces were aligned against C, C++
 and Java, but the forces were overcome.  In each case, rational
 examination of the languages revealed advantages as well as
 non-rational forces, such as Sun's marketing and glitter in the case
 of Java, strengthening the prospects of the language's adaption. I
 hope we can both agree that change will come.

 But, I do not believe the change will be revolutionary but, rather,
 evolutionary. A language that evolves from an existing ecosystem has a
 much greater likelihood of becoming significant than a green field
 language.

 I paint and sculpt as well as do mathematics and physics and, for me,
 language selection is far closer to math and physics than to the play
 of colors or shape and form. I, thus, do not agree that choosing a
 programming language is an exercise in artistry, but rather, its a
 more rational process.  And, if beauty is involved, then it is
 scientific beauty and not artistic beauty.  Are you Picasso? Maybe
 even Mondrian? Hopefully, not Pollock.

 Concerning the languages you listed as the way forward, an important
 criteria must be: where are the programmers coming from?  One can wait
 for a new generation or one can see if any existing programmers will
 migrate from their current language to a new language.  Some language
 usages from the web:
    Java         18%
    C            16%
    C++           9%
    Python        6%
    C#            6%
    Objective-C   3%
    Ruby          2%
    Lisp          1%
    Scheme       ~0.5%
    Haskell      ~0.3%
    Scala        ~0.3%
    Eiffel       0.1%
    Clojure      ~0.0%

 So, where might future Haskell or Clojure or Eiffel or Scala
 programmers come from?

 # So, what about Eiffel?

 Eiffel (with DbC, design by contract) is a 25 year old language and
 its usage stats are down in the noise - well below Scala, Clojure and
 Haskell - and showing its age. Hard to see a ground swell of C or Java
 programmers switching to Eiffel.

 Eiffel's grasp exceeded what could be supported; its notion of
 contract was so big, it was hard to find a wrapper around it all.
 Category Theory may provide for a pragmatic approach to reasoning
 about interfaces (contracts) which might not encompass all possible
 rely/guarantee predicates, but many.  As such, the three laws of
 Monads from Category Theory might yield a more coherent, reasoned
 approach to DbC and interface design.  Curiously, this has been
 discussed by the author of Scala as a possible approach to adding DbC
 to Scala. For the Scala-CLR binding there is native support for such
 constructs while for the Scala-JVM binding, it would have to be done
 with code.


 # So, what about Haskell?

 Haskell is the flag ship FP testbed which has been out there for close
 to 20 years. There are no large enterprise applications written in
 Haskell. It has certainly not taking the programming world by storm
 whatever its merits.  In addition, for Haskell, and all FP languages
 for that matter, the world view required is not shared by most people,
 Folks do not 

Re: Scala-Wicket Help and Advice

[Martin Makundi]

One can always get better at following but tools must improve to be
better for building  ;)

**
Martin

2011/1/11 Rodolfo Hansen kry...@gmail.com:
 I guess Project Lombok could be extended for this.

 You would be inviting the same problems encountered by C++ with its
 multiple inheritance,
 and all that magic will probably make things harder to follow.

 But; like all shotguns, it's everyone's responsibility where they aim,
 lest they shoot themselves in the foot.

 :D


 On Sun, 2011-01-09 at 10:00 +0200, Martin Makundi wrote:

  Either way, you have to put logic somewhere that tries to figure out
  what the heck you want to borrow and then figure out where the heck to
  get it.
 
  If it is done at compile time you don't need messaging logic. It
  would be uniquely defined what you can get.
 
  Please explain.

 Think about object hierarchy. It is uniquely defined what method
 overrides what etc.

 So it would just expand the same idea to membership dimensions in
 addition to inheritance dimensions.

 I mean that assuming man has a bag would work effectively similar to
 man extends bag at compile time.

 If bag has a getter then man can expose that getter. However, if we
 would really extend bag then we are stuck with it (and we could'nt
 have man wear both jacket, trousers and bag at same time).

 When man only has bag then we can also change the bag and extend the
 bag with another bag or set it to null even.

 Nevertheless, we could annotate:

 @DefaultExpose(ExposeLevels.ALL)
 public class Man {
  private Bag bag;
 }

 public class Customs {
    public boolean investigate(Man man) {
       Pencil = man.getPencil();
    }
 }

  Alternatively you can move the annotation

 public class Man {
 �...@defaultexpose(ExposeLevels.ALL)
  private Bag bag;
 }

 ::: or even more detailed:

 public class Bag {
 �...@defaultexpose(ExposeLevels.ALL)
  private PencilCase pencilCase;
 }


 Override rules could be same as as if the Man extended Bag and as if
 Bag extened PencilCase.

 **
 Martin

Re: Scala-Wicket Help and Advice

[Martin Makundi]

 Either way, you have to put logic somewhere that tries to figure out
 what the heck you want to borrow and then figure out where the heck to
 get it.

 If it is done at compile time you don't need messaging logic. It
 would be uniquely defined what you can get.

 Please explain.

Think about object hierarchy. It is uniquely defined what method
overrides what etc.

So it would just expand the same idea to membership dimensions in
addition to inheritance dimensions.

I mean that assuming man has a bag would work effectively similar to
man extends bag at compile time.

If bag has a getter then man can expose that getter. However, if we
would really extend bag then we are stuck with it (and we could'nt
have man wear both jacket, trousers and bag at same time).

When man only has bag then we can also change the bag and extend the
bag with another bag or set it to null even.

Nevertheless, we could annotate:

@DefaultExpose(ExposeLevels.ALL)
public class Man {
 private Bag bag;
}

public class Customs {
   public boolean investigate(Man man) {
  Pencil = man.getPencil();
   }
}

 Alternatively you can move the annotation

public class Man {
 @DefaultExpose(ExposeLevels.ALL)
 private Bag bag;
}

::: or even more detailed:

public class Bag {
 @DefaultExpose(ExposeLevels.ALL)
 private PencilCase pencilCase;
}


Override rules could be same as as if the Man extended Bag and as if
Bag extened PencilCase.

**
Martin

Re: Scala-Wicket Help and Advice

[Martin Makundi]

  Analysis is the a background process that parses the file and highlights
 errors, warnings, etc while you type.  Eclipse has the same, though the name
 may be different.  It's slow in Scala, like compilation is.

If it is slow then it is pain. Computer speeds might enhance faster than ides ;)

  Yes, it gives you context help.  It's very helpful with a caveat:  in
 Scala, there are several implicit conversions (String to RichString, etc)
 that may take place depending on what method you invoke.  IDEA tries to be
 smart and preview the methods that would be accessible if any valid
 transformation for your current type would be accessible, resulting in too
 many matches.

Ouch.

What I hate about java is its one-dimensionality... ehh.. say you have:

object man
object man carrying bag
bag carrying pencil case.

Now I want the man to hand me the pencil, I must implement:
* man.getpencil-man.getbag.getpencil
* bag.getpencil-bag.getpencilcase.getpencil
* pencilcase.getpencil

In real business cases this is very OK, but usually there are 90% just
dummy getters and 10% are real business objects like transfer money
in avery safe and robust manner...

I whish there was an easy way to transparently penetrate beans. I
could actually call man.getPencil and it would be authorized to fetch
it from bag,pencilcase.

Ofcourse I could configure exceptions to the rule, but in general I
could say that it is allowed in general or it is not allowed in
general. And maybe annotate access rules.

Maybe there is a compile time tool that does just this already for
java? Something like bindgen or Project Lombok?

That is the next foreseeable obstacle in making java efficient.
After that it's maybe time for fancy functional proframming or
multiple inheritance ;)

**
Martin




 On Sat, Jan 8, 2011 at 1:34 AM, James Carman 
 ja...@carmanconsulting.comwrote:

 Since scala is statically-typed, the ide can (and does) give you contextual
 help very easily
 On Jan 8, 2011 2:21 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com
 wrote:
   But it will do the right thing about 90% of the time. you'll
 subconsciously
  work around 4 or 5% of the rest that doesn't work, and the remaining
 5-6%
  will irritate you.
 
  I am used to coding 90% using context help with eclipse (ctrl+space).
  I am a fast writer but that speeds up my coding by 1000%.
 
  Will an IDE do that for scala 90%?
 
  I consider context help and quickfix proposals most important for speedy
 work.
 
  - imports sometimes get messed up (relative vs absolute, I hate that in
  scala) and require a manual correction
 
  Import organization is important to me also. I like to spend my time
  coding logic instead of organizing text files.
 
  - analysis is useful about 90% of the time, but it's so slow you may
 just
  not care for it
 
  What is analysis? I hope it isn't the context help ;)
 
 
 
  **
  Martin
 
  - it crashes the JVM on Oracle's JRockit (although IDEA is much faster
 in
  that jvm)
 
 
  On Fri, Jan 7, 2011 at 5:37 PM, Liam Clarke-Hutchinson
  l...@steelsky.co.nzwrote:
 
  Define complete.
 
  On Sat, Jan 8, 2011 at 7:52 AM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
   Nice or complete?
  
   **
   Martin
  
   2011/1/7 Jonathan Locke jonathan.lo...@gmail.com:
   
Have you checked out IDEA? My Scala friends tell me it has pretty
 nice
   Scala
support.
   
Jon
   
Less is more.
   
  
 
 http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/
   
--
View this message in context:
  
 

 http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html
Sent from the Forum for Wicket Core developers mailing list archive
 at
   Nabble.com.
   
  
 
 

Re: Scala-Wicket Help and Advice

[Martin Makundi]

Hi!

 You would use a more domain-oriented design approach.  Setters/getters
 are merely used because of all the frameworks that support (and
 expect) them.  Why do you care where the man is carrying his pencil?
 Perhaps he's keeping it in his sock. All you want to do is ask the man
 object for a pencil.

Yes.

 Having to go through his carrying bag to his
 pencil case to get his pencil is exposing the implementation.

I don't plan to expose implementation. I just want to make the
implementation inside the man. But more easily.

 However, if you have to ask him for the pencil and then he can go dig
 in his bag to get his pencil case to find a pencil, then perhaps he can do
 something at that point and jot down a note that you've just borrowed
 a pencil from him.

This is correct but I want to streamline the implementation of he can go dig
in his bag to get his pencil case to find a pencil.

Again, the more complex you make the example (jot down a note that
you've just borrowed from him) the more special and rare case you
make it. That's not what I am after to simplify. I want to simplify
the 90% of cases where it is ONLY about GET an item without
interventions.

It should be possible to say that man will proxy by default all get
methods of his belongings, It should be possible to say that bag
will proxy by default all get methods of his belongings. Same with
pencil casing. In such situation i wouldn't need to CODE all thsoe
get.get.get.get methods but the framework or compilation procedure
would provide them automatically.

WHEN I want to intervene the GET method (and track borrowed pencils
for example) I could just override the man.getPencil explicitly to do
that.

**
Martin

Re: Scala-Wicket Help and Advice

[Martin Makundi]

Hi!

 public T T borrowObject(ClassT objectType)

 where you can do

 Pencil p = man.borrowObject(Pencil.class);

 Either way, you have to put logic somewhere that tries to figure out
 what the heck you want to borrow and then figure out where the heck to
 get it.

If it is done at compile time you don't need messaging logic. It
would be uniquely defined what you can get.

 I don't necessarily think I would consider this a shortcoming
 of the Java language.

Well.. if there is room for improvement it could be considered a
shortcoming. Solution is not necessarily simple, but possible ;)

**
Martin

Re: Scala-Wicket Help and Advice

[Martin Makundi]

I would adopt scala immediately if it had all the IDE tools Java has
with equal reliability (amount of showstopper/awkward bugs).

So guess it's just a matter of time, if nobody comes up with something better.

Lots of people are taught into coding java (as if that helps ;), so
one day when people are taught scala or its successors, it might be
perceived more mainstreamn than now.

Anywayz.. in 50 yrs or so, computers will be doing the coding automatically ;))

**
Martin

2011/1/7 Jonathan Locke jonathan.lo...@gmail.com:

 Kuhn's The Structure of Scientific Revolutions has to do with people
 denying *the truth* when there are radical paradigm shifts in knowledge. I
 hardly think Scala qualifies for this analogy. Most of what Scala does has
 already been done in one form or another. What it represents is the
 application of long-existing knowledge from universities to *industrial*
 problems. As did Java.

 I do not deny that Scala is better than Java in terms of its abstract
 approach to a variety of problems that Java doesn't and probably never will
 solve well (and these are problems that I am excited to see solved). What I
 am saying, however, is that your idea that it's going to get widespread
 adoption is very naive regarding the contexts where it would need to be
 applied. I think Scala is going to become difficult to follow in the absence
 of these magical coding guidelines (which are always bent or ignored) much
 more quickly than Java does, which means it is going to prove exceptionally
 hard to manage on a large team. Which is going to make it difficult for
 managers to chose Scala (they don't want to make their own job harder or
 riskier). They have to understand and be comfortable with all these deep and
 dangerous features and techniques. Which really means that they have to be
 fairly top-flight coders. I don't know about you, but relatively few of my
 bosses have been this intellectually adventurous or willing to take on risk
 (and for good reason: they are there (unfortunately perhaps) to produce
 business results, not technical excellence).

 I think Scala's forte is going to be allowing very small teams where
 everyone understands all aspects of Scala fairly deeply (i.e., you'd better
 understand monads and Scala's type system fully because SOMEONE on your team
 will use a feature or technique if it exists!) to produce amazing results
 *very* quickly. That is something of a revolution in itself, but I think it
 will be a cottage industry relative to the size rest of the software
 industry. This is not necessarily a bad thing. If you want to work with
 smart people, Scala is going to be a pretty quick way of identifying smart
 people! I know this from experience: I can't even understand on several
 readings a lot of my friend Greg's posts about Scala and monads and
 mathematics. I would need to go back to graduate school in math and I'd
 probably need an IQ upgrade to boot.

 I know this sounds awfully Dilbert (and maybe that's who I've become), but
 at a mid-sized or large company (which is where most people work), what you
 want in a language is something that protects you from your co-workers. In
 my experience, even the advanced features of C++ and Java have
 consistently been abused and even wrecked whole projects.

 All this said, Scala is probably a god-send to small startups and university
 spin-offs. And I think it's an important stake in the ground because it
 references a future wider-scale industrial software revolution that
 eventually will occur when someone more practical sits down and figures out
 how to pack Scala's features (and some things it didn't address) into a
 language that's as easy to learn and read and work with as Java. My advice
 to you is this: don't get caught up in the politics of technology adoption.
 You will only find yourself frustrated and disappointed because at the end
 of the day, it's a business world not a technology world. Instead go find
 the cool kids and hack away in Scala on some crazy new startup that really
 will change the world. Odds are you'll beat the pants off your Java-based
 competitors on time-to-market. And if you're wondering why I don't do that,
 it's because of all this green paper stuff they keep throwing at me. Maybe I
 really have gotten old.

 Jon

 Less is more.
 http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3181566.html
 Sent from the Forum for Wicket Core developers mailing list archive at 
 Nabble.com.

Re: Scala-Wicket Help and Advice

[Martin Makundi]

Nice or complete?

**
Martin

2011/1/7 Jonathan Locke jonathan.lo...@gmail.com:

 Have you checked out IDEA? My Scala friends tell me it has pretty nice Scala
 support.

 Jon

 Less is more.
 http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html
 Sent from the Forum for Wicket Core developers mailing list archive at 
 Nabble.com.

Re: Scala-Wicket Help and Advice

[Martin Makundi]

  But it will do the right thing about 90% of the time. you'll subconsciously
 work around 4 or 5% of the rest that doesn't work, and the remaining 5-6%
 will irritate you.

I am used to coding 90% using context help with eclipse (ctrl+space).
I am a fast writer but that speeds up my coding by 1000%.

Will an IDE do that for scala 90%?

I consider context help and quickfix proposals most important for speedy work.

 - imports sometimes get messed up (relative vs absolute, I hate that in
 scala) and require a manual correction

Import organization is important to me also. I like to spend my time
coding logic instead of organizing text files.

 - analysis is useful about 90% of the time, but it's so slow you may just
 not care for it

What is analysis? I hope it isn't the context help ;)



**
Martin

 - it crashes the JVM on Oracle's JRockit (although IDEA is much faster in
 that jvm)


 On Fri, Jan 7, 2011 at 5:37 PM, Liam Clarke-Hutchinson
 l...@steelsky.co.nzwrote:

 Define complete.

 On Sat, Jan 8, 2011 at 7:52 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  Nice or complete?
 
  **
  Martin
 
  2011/1/7 Jonathan Locke jonathan.lo...@gmail.com:
  
   Have you checked out IDEA? My Scala friends tell me it has pretty nice
  Scala
   support.
  
   Jon
  
   Less is more.
  
 
 http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/
  
   --
   View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html
   Sent from the Forum for Wicket Core developers mailing list archive at
  Nabble.com.
  
 

Re: more explicit handling of null values - yay or nay?

[Martin Makundi]

How would it simplify actual code?

**
Martin

2011/1/5 Igor Vaynberg igor.vaynb...@gmail.com:
 ive recently ran into a few cases where while implementing
 ajaxfallbacklink i forgot to test the passed in request target for
 null, causing NPEs when the app was accessed from browsers where ajax
 failed for whatever reason.

 with all this talk of scala recently i figured why not try and
 translate one of the feature i really like in scala Option/Null/Some
 to our code base.

 i came up with a simple value class:
 https://gist.github.com/c38456ee75fed541c932

 and changed the ajaxfallbacklink to use it
 https://gist.github.com/2f648c7feacacf18fc40

 the cascade from this change was pretty impressive, a lot of places in
 our code support passing a possibly null request target but make no
 mention of it:
 https://gist.github.com/d9933e24c21f061c6ac2

 so advantages:
 makes possible null value handling explicit
 no more checking the javadoc to see if the method supports null as a
 parameter value or ever returns a null
 an api break before 1.5 rc1
 i think overall makes lives of wicket users easier

 disadvantages:
 a bit wordier code
 an api break just about when we are ready to release 1.5 m4/rc1
 whatever we call it

 yay or nay? obviously if we say yay there are a lot more places in our
 code that can benefit from this

 -igor

Re: more explicit handling of null values - yay or nay?

[Martin Makundi]

We use only Ajax or non-Ajax components. No fallbacks. I think in the
(near) future we don't really need fallbacks. Everything is javascript
nowdays. Only mammooths are fallback.

From that perspective it seems excess to add code to make something
nice that is not going to exist for long.

Ofcourse the opposite is also true, if we make fallbacks very
comfortable and widely supported, people will continue using
non-javascript devices longer than necessary.

**
Martin

2011/1/5 Pedro Santos pedros...@gmail.com:
 Not simplifing (not complicating also), but making clear that an specific
 parameter is optional, it can prevent some runtime NPE by exposing in a very
 clear way at development time that some parameter may be null.

 On Wed, Jan 5, 2011 at 3:53 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 How would it simplify actual code?

 **
 Martin

 2011/1/5 Igor Vaynberg igor.vaynb...@gmail.com:
  ive recently ran into a few cases where while implementing
  ajaxfallbacklink i forgot to test the passed in request target for
  null, causing NPEs when the app was accessed from browsers where ajax
  failed for whatever reason.
 
  with all this talk of scala recently i figured why not try and
  translate one of the feature i really like in scala Option/Null/Some
  to our code base.
 
  i came up with a simple value class:
  https://gist.github.com/c38456ee75fed541c932
 
  and changed the ajaxfallbacklink to use it
  https://gist.github.com/2f648c7feacacf18fc40
 
  the cascade from this change was pretty impressive, a lot of places in
  our code support passing a possibly null request target but make no
  mention of it:
  https://gist.github.com/d9933e24c21f061c6ac2
 
  so advantages:
  makes possible null value handling explicit
  no more checking the javadoc to see if the method supports null as a
  parameter value or ever returns a null
  an api break before 1.5 rc1
  i think overall makes lives of wicket users easier
 
  disadvantages:
  a bit wordier code
  an api break just about when we are ready to release 1.5 m4/rc1
  whatever we call it
 
  yay or nay? obviously if we say yay there are a lot more places in our
  code that can benefit from this
 
  -igor
 




 --
 Pedro Henrique Oliveira dos Santos

Re: overriding isVisible bad?

[Martin Makundi]

What about using onconfigure to replace loadabledetachablemodel ? We
have had some trouble with loadabledetachablemodels when their state
is frozen before a dependent model has been initialized (for example)
and we need to call model.detach() from within our code, which seems
bit hacky.

Initializing also models at a specific known requestcycle moment might
be beneficial. Ofcourse it is not so straightforward as with
enable/visible state.

**
Martin

2010/12/1 Igor Vaynberg igor.vaynb...@gmail.com:
 i would be happy if that was good enough. in the past it hasnt been,
 thats why we have the current solution. maybe we can try it again in
 1.5 and see what happens.

 -igor

 On Tue, Nov 30, 2010 at 11:44 AM, Pedro Santos pedros...@gmail.com wrote:
 I have a different point of view, the HTTP imposes us some limitations, we
 will hardly have an good synchronization between the component state on
 browser and server using only HTTP conversation. So it is mandatory the
 service layer to respect the described security restriction.

 On Tue, Nov 30, 2010 at 5:32 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 an easy example is security.

 a user views a page that allows them to delete another user
 meanwhile their permissions are tweaked and they can no longer delete
 other users
 half an hour later the user clicks the delete button - this should
 fail, but wont if we are using last-rendered state.

 -igor

 On Tue, Nov 30, 2010 at 11:18 AM, Pedro Santos pedros...@gmail.com
 wrote:
  I need to look better on which core components are relying on an updated
  visibility/enabled state at the process event time, and why the last
  rendered state wouldn't be enough to them to work nicely.
 
  On Tue, Nov 30, 2010 at 3:19 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  currently we only invoke configure before the render. this would mean
  we would have to invoke it before processing a listener, clearing the
  cache, and then invoking it again before render. i wonder if that is
  enough places to invoke it
 
  -igor
 
  On Tue, Nov 30, 2010 at 9:15 AM, Pedro Santos pedros...@gmail.com
 wrote:
   If user click an link, it will change the value of some property at
 the
   process_event request cycle step. Then the processor will go to the
  respond
   step, will invoke every component before render method which will end
 up
   invoking the Component#configure and updating the visibility/enabled
  state
   (even if it changes, we are able to work with the updated state). So
 when
   the this component has the opportunity to render it self, it will be
  aware
   its update state.
  
   On Tue, Nov 30, 2010 at 2:39 PM, Igor Vaynberg 
 igor.vaynb...@gmail.com
  wrote:
  
   there are other places that should be checked though. for example
   before we invoke a listener on the component we should check again to
   make sure that visibility hasnt changed. eg if visibility depends on
   some property of the user clicking the link that changed between
   render and clicking the link.
  
   -igor
  
   On Tue, Nov 30, 2010 at 8:30 AM, Pedro Santos pedros...@gmail.com
  wrote:
An implementation idea:
   
Component {
   public final void configure()
   {
       if (!getFlag(FLAG_CONFIGURED))
       {
           setVisible_NoClientCode(isVisible()); //we only check
 the
  user
isVisible in here
           onConfigure();
           setFlag(FLAG_CONFIGURED, true);
       }
   }
}
   
On Tue, Nov 30, 2010 at 2:16 PM, Igor Vaynberg 
  igor.vaynb...@gmail.com
   wrote:
   
so how is it different if they can still override something that
  needs
to be checked all the time?
   
-igor
   
On Tue, Nov 30, 2010 at 8:02 AM, Pedro Santos 
 pedros...@gmail.com
   wrote:
 I understand the concern about possible isVisible
 implementations
  like

 isVisible(return currentlyTime  10:00:00;) //imagine this
  component
being
 rendered at 09:59:59
 isVisible(return dao.list().size()  0);// performance issues

 But maybe we can have the best from both approaches. This is an
copy/paste
 from java.awt.Component:

    public boolean isVisible() {
        return isVisible_NoClientCode();
    }
    final boolean isVisible_NoClientCode() {
        return visible;
    }

 There are some points in the awt framework were the isVisible
  method
   is
not
 used in benefit of isVisible_NoClientCode
 I'm in favor of create an final isVisible/Enabled version and
  change
   the
 Wicket core to use it. Also maintain the hotspot to users
 provide
   their
 isVisible/Enable implementations that will serve to feed the
 core
component
 state.

 On Mon, Nov 29, 2010 at 4:56 PM, Igor Vaynberg 
   igor.vaynb...@gmail.com
wrote:

 ive run into plenty of weird problems with overrides, but maybe
 because this was in a high concurrency app where data changed
 

Re: isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?

[Martin Makundi]

Hi!

The fix I proposed does fix the probelm at hand but it makes page
rendering tremendeously slow due to the recursion:


Component componentParent = component.getParent();

is a recursive call that will be called O(n^n) times in hierarcy.


Something else must be proposed to fix this? The isEnabledInHierarchty
uses a caching mechanism. Maybe this will also need to cache the
isparentvisible at each level thus avoiding O(n^n) recursion.

Any suggestions how to speed it up?

**
Maritin



2010/11/13 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 Created jira issue at https://issues.apache.org/jira/browse/WICKET-3166

 2010/11/12 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 I have a page with two panels:

 page.add(panel1);
 page.add(panel2);

 in some situations panel1 is not visible.

 However, a form submit event will visit all formcomponents of panel1 via:

        at 
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
        at 
 org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
        at 
 org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
        at 
 org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)

 This results in a crash because panel1 components are not prepared to
 be invoked via isvisible when the panel itself is not visible.

 I wonder if the component.isVisibleInHierarchy could be changed as
 follows, to first check parent visibility:

  public final boolean isVisibleInHierarchy()
  {
    Component component = this;
    while (component != null)
    {
      Component componentParent = component.getParent();

      if (((componentParent == null) ||
 componentParent.isVisibleInHierarchy()) 
 component.determineVisibility())
      {
        component = componentParent;
      }
      else
      {
        return false;
      }
    }
    return true;
  }

 Similar change could/should maybe be possible also for isEnabledInHierarchy ?

 Comments?

 **
 Martin

Re: isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?

[Martin Makundi]

Hah..

actually there is an unnecessary recursion in the proposal. The
while-loop is no longer needed if parent is already called.

**
Martin

2010/11/14 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 The fix I proposed does fix the probelm at hand but it makes page
 rendering tremendeously slow due to the recursion:


 Component componentParent = component.getParent();

 is a recursive call that will be called O(n^n) times in hierarcy.


 Something else must be proposed to fix this? The isEnabledInHierarchty
 uses a caching mechanism. Maybe this will also need to cache the
 isparentvisible at each level thus avoiding O(n^n) recursion.

 Any suggestions how to speed it up?

 **
 Maritin



 2010/11/13 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 Created jira issue at https://issues.apache.org/jira/browse/WICKET-3166

 2010/11/12 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 I have a page with two panels:

 page.add(panel1);
 page.add(panel2);

 in some situations panel1 is not visible.

 However, a form submit event will visit all formcomponents of panel1 via:

        at 
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
        at 
 org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
        at 
 org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
        at 
 org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)

 This results in a crash because panel1 components are not prepared to
 be invoked via isvisible when the panel itself is not visible.

 I wonder if the component.isVisibleInHierarchy could be changed as
 follows, to first check parent visibility:

  public final boolean isVisibleInHierarchy()
  {
    Component component = this;
    while (component != null)
    {
      Component componentParent = component.getParent();

      if (((componentParent == null) ||
 componentParent.isVisibleInHierarchy()) 
 component.determineVisibility())
      {
        component = componentParent;
      }
      else
      {
        return false;
      }
    }
    return true;
  }

 Similar change could/should maybe be possible also for isEnabledInHierarchy 
 ?

 Comments?

 **
 Martin

Re: isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?

[Martin Makundi]

Hi!

Created jira issue at https://issues.apache.org/jira/browse/WICKET-3166

2010/11/12 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 I have a page with two panels:

 page.add(panel1);
 page.add(panel2);

 in some situations panel1 is not visible.

 However, a form submit event will visit all formcomponents of panel1 via:

        at 
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
        at 
 org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
        at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
        at 
 org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)

 This results in a crash because panel1 components are not prepared to
 be invoked via isvisible when the panel itself is not visible.

 I wonder if the component.isVisibleInHierarchy could be changed as
 follows, to first check parent visibility:

  public final boolean isVisibleInHierarchy()
  {
    Component component = this;
    while (component != null)
    {
      Component componentParent = component.getParent();

      if (((componentParent == null) ||
 componentParent.isVisibleInHierarchy()) 
 component.determineVisibility())
      {
        component = componentParent;
      }
      else
      {
        return false;
      }
    }
    return true;
  }

 Similar change could/should maybe be possible also for isEnabledInHierarchy ?

 Comments?

 **
 Martin

isVisibleInHierarchy() possibly unnecessarily checks children whose parents are invisible?

[Martin Makundi]

Hi!

I have a page with two panels:

page.add(panel1);
page.add(panel2);

in some situations panel1 is not visible.

However, a form submit event will visit all formcomponents of panel1 via:

at 
org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:400)
at 
org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:1209)
at org.apache.wicket.markup.html.form.Form.inputChanged(Form.java:1403)
at 
org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:865)

This results in a crash because panel1 components are not prepared to
be invoked via isvisible when the panel itself is not visible.

I wonder if the component.isVisibleInHierarchy could be changed as
follows, to first check parent visibility:

  public final boolean isVisibleInHierarchy()
  {
Component component = this;
while (component != null)
{
  Component componentParent = component.getParent();

  if (((componentParent == null) ||
componentParent.isVisibleInHierarchy()) 
component.determineVisibility())
  {
component = componentParent;
  }
  else
  {
return false;
  }
}
return true;
  }

Similar change could/should maybe be possible also for isEnabledInHierarchy ?

Comments?

**
Martin

Re: Welcome Martin Grigorov as a core team member

[Martin Makundi]

Ok. We are currently testing it and if you have any test code snipplet
requests, please just comment on the ticket and we will provide what
you need whereas wickettester/junit are concerned.

**
Martin

2010/11/9 Martin Grigorov mgrigo...@apache.org:
 Hi Martin,

 I am aware of the ticket.
 Last two weeks there are several tickets/discussions about ModalWindow. The
 problem is that it is used by many people and we have to be careful with the
 fixes there.
 I also saw your comment on WICKET-2053, so we will take a look at it as well
 when we star looking at it.

 On Tue, Nov 9, 2010 at 8:07 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Hi Martin!

 Pls take a look at a fix for ModalWindows that are nested inside IFrame:

 https://issues.apache.org/jira/browse/WICKET-3151

 This wasn't supported before but Rodolfo kindly added support for it
 and fixed some bugs in it.

 **
 Martin


  Tue, 20 Jul 2010 08:54:07 -0700 Martin Grigorov
 
  Just feed me with patches for 1.4 ;-)
 
  2010/7/20 Johan Compagner jcompag...@gmail.com
 
   welcome!
  
   hope you happily merge even more stuff ;)
  
   johan

Re: Welcome Martin Grigorov as a core team member

[Martin Makundi]

 Don't hesitate to attach quickstart app or tests to any of the tickets.
 This is one of the reasons the Wicket team invited me to join them :-)

The problem is that this is a drop-in replacement/fix for modal
window, it should pass all existing modal window tests. So there isn't
really any new wicket-level functionality to test. All changes are in
javascript. Is it possible to drop in selenium tests?

**
Martin


 On Tue, Nov 9, 2010 at 10:44 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Ok. We are currently testing it and if you have any test code snipplet
 requests, please just comment on the ticket and we will provide what
 you need whereas wickettester/junit are concerned.

 **
 Martin

 2010/11/9 Martin Grigorov mgrigo...@apache.org:
  Hi Martin,
 
  I am aware of the ticket.
  Last two weeks there are several tickets/discussions about ModalWindow.
 The
  problem is that it is used by many people and we have to be careful with
 the
  fixes there.
  I also saw your comment on WICKET-2053, so we will take a look at it as
 well
  when we star looking at it.
 
  On Tue, Nov 9, 2010 at 8:07 AM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  Hi Martin!
 
  Pls take a look at a fix for ModalWindows that are nested inside IFrame:
 
  https://issues.apache.org/jira/browse/WICKET-3151
 
  This wasn't supported before but Rodolfo kindly added support for it
  and fixed some bugs in it.
 
  **
  Martin
 
 
   Tue, 20 Jul 2010 08:54:07 -0700 Martin Grigorov
  
   Just feed me with patches for 1.4 ;-)
  
   2010/7/20 Johan Compagner jcompag...@gmail.com
  
welcome!
   
hope you happily merge even more stuff ;)
   
johan
 
 

Re: Welcome Martin Grigorov as a core team member

[Martin Makundi]

Thanx, we will do that and attach tests. Let us know then if something
is missing.

**
Martin

2010/11/9 Martin Grigorov mgrigo...@apache.org:
 Javascript changes are the most problematic ones ...
 It is easy to do it for latest versions of Firefox, IE8 and Chrome, but then
 people come with IE6/7 or Safari and start filing tickets ...

 If you can create Selenium/WebDriver/... tests for wicket-examples  ajax 
 modal window this will be the best.
 You can even extend the example to use nested iframe for this ticket.

 On Tue, Nov 9, 2010 at 11:01 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  Don't hesitate to attach quickstart app or tests to any of the tickets.
  This is one of the reasons the Wicket team invited me to join them :-)

 The problem is that this is a drop-in replacement/fix for modal
 window, it should pass all existing modal window tests. So there isn't
 really any new wicket-level functionality to test. All changes are in
 javascript. Is it possible to drop in selenium tests?

 **
 Martin

 
  On Tue, Nov 9, 2010 at 10:44 AM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  Ok. We are currently testing it and if you have any test code snipplet
  requests, please just comment on the ticket and we will provide what
  you need whereas wickettester/junit are concerned.
 
  **
  Martin
 
  2010/11/9 Martin Grigorov mgrigo...@apache.org:
   Hi Martin,
  
   I am aware of the ticket.
   Last two weeks there are several tickets/discussions about
 ModalWindow.
  The
   problem is that it is used by many people and we have to be careful
 with
  the
   fixes there.
   I also saw your comment on WICKET-2053, so we will take a look at it
 as
  well
   when we star looking at it.
  
   On Tue, Nov 9, 2010 at 8:07 AM, Martin Makundi 
   martin.maku...@koodaripalvelut.com wrote:
  
   Hi Martin!
  
   Pls take a look at a fix for ModalWindows that are nested inside
 IFrame:
  
   https://issues.apache.org/jira/browse/WICKET-3151
  
   This wasn't supported before but Rodolfo kindly added support for it
   and fixed some bugs in it.
  
   **
   Martin
  
  
Tue, 20 Jul 2010 08:54:07 -0700 Martin Grigorov
   
Just feed me with patches for 1.4 ;-)
   
2010/7/20 Johan Compagner jcompag...@gmail.com
   
 welcome!

 hope you happily merge even more stuff ;)

 johan
  
  
 
 

Re: Welcome Martin Grigorov as a core team member

[Martin Makundi]

Hi Martin!

Pls take a look at a fix for ModalWindows that are nested inside IFrame:

https://issues.apache.org/jira/browse/WICKET-3151

This wasn't supported before but Rodolfo kindly added support for it
and fixed some bugs in it.

**
Martin


 Tue, 20 Jul 2010 08:54:07 -0700 Martin Grigorov

 Just feed me with patches for 1.4 ;-)

 2010/7/20 Johan Compagner jcompag...@gmail.com

  welcome!
 
  hope you happily merge even more stuff ;)
 
  johan

Bug ? form.isMultiPart().anyEmbeddedMultipart picks multipart also from hidden items?

[Martin Makundi]

Hi!

Is it a bug or a feature that

form.isMultiPart().anyEmbeddedMultipart

picks ismultipart also from hidden nested forms (that are not visible
in hierarchy)?

form
  modalwindow
  panel
   form-with-multipart-but-not-visible-before-modalwindow-is-opened

**
Martin

Re: Bug ? form.isMultiPart().anyEmbeddedMultipart picks multipart also from hidden items?

[Martin Makundi]

Ah.. ok. My bad, old version:

visitChildren(Component.class, new IVisitorComponent()
{
public Object component(Component component)
{
boolean isMultiPart = false;
if (component instanceof Form)
{
Form? form = (Form?)component;
isMultiPart = (form.multiPart != 0);
}
else if (component instanceof FormComponent)
{
FormComponent? form = 
(FormComponent?)component;
isMultiPart = form.isMultiPart();
}
if (isMultiPart == true)
{
anyEmbeddedMultipart[0] = true;
return STOP_TRAVERSAL;
}
return CONTINUE_TRAVERSAL;
}

});


2010/10/26 Martin Grigorov mgrigo...@apache.org:
 This is how the code looks (Form.java, 1.4-SNAPSHOT):

 visitChildren(Component.class, new IVisitorComponent()
 {
 public Object component(Component component)
 {
 boolean isMultiPart = false;
 if (component instanceof Form)
 {
 Form? form = (Form?)component;

 if (form.isVisibleInHierarchy()  form.isEnabledInHierarchy())
 {
 isMultiPart = (form.multiPart != 0);
 }
 }
 else if (component instanceof FormComponent)
 {
 FormComponent? fc = (FormComponent?)component;
 if (fc.isVisibleInHierarchy()  fc.isEnabledInHierarchy())
 {
 isMultiPart = fc.isMultiPart();
 }
 }

 if (isMultiPart == true)
 {
 anyEmbeddedMultipart[0] = true;
 return STOP_TRAVERSAL;
 }
 return CONTINUE_TRAVERSAL;
 }

 });

 So it takes into account the visibility

 On Tue, Oct 26, 2010 at 2:20 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Hi!

 Is it a bug or a feature that

 form.isMultiPart().anyEmbeddedMultipart

 picks ismultipart also from hidden nested forms (that are not visible
 in hierarchy)?

 form
  modalwindow
      panel
           form-with-multipart-but-not-visible-before-modalwindow-is-opened

 **
 Martin

ModalWindow inside modalwindow in iframe not supported?

[Martin Makundi]

Hi!

Why is this not fixed /fixable:

http://www.mail-archive.com/comm...@wicket.apache.org/msg10857.html
https://issues.apache.org/jira/browse/WICKET-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

There is a fix proposal, so why not?



**
Martin

Re: 1.4.13 release?

[Martin Makundi]

Since you are asking ;-)

https://issues.apache.org/jira/browse/WICKET-2729

2010/10/16 Jeremy Thomerson jer...@wickettraining.com:
 Anybody interested in a 1.4.13 release in the coming week?  Anything that
 you'd like to get in before it's built?  I may have some time next week to
 do it.

 --
 Jeremy Thomerson
 http://www.wickettraining.com

Re: [jira] Commented: (WICKET-2967) org.apache.wicket.util.value.Count: add decrement method

[Martin Makundi]

It's an automated list so you are responsible for both subscribing and
unsubscribing yourself.

**
Martin

2010/7/26 Steven Tierney steven.tier...@brightpurple.co.uk:
 Please un subscribe me from this mailing list

 Thanks



 Steven Tierney
 Bright Purple Resourcing Ltd
 Senior ConsultantBR
 The Eagle Building, 19 Rose Street, Edinburgh, EH2 2PR

 Office:   +44 131 473 7045 (Direct Line)
          +44 131 473 7030
 Fax:      +44 131 473 7040
 Website:  www.brightpurple.co.uk
 Twitter:  twitter.com/BrightPurpleR

 Bright Purple Resourcing - “PERFECTLY PLACING PROFESSIONALS SINCE 1995”

 Think before you print. Please do not print this email unless you really need 
 to.

 Any views or opinions presented in this email are solely
 those of the author and do not necessarily represent those of the company.
 Employees of Bright Purple Resourcing are expressly required not to make 
 defamatory statements and not to infringe or authorise any infringement of 
 copyright or any other legal right by email communications. Any such 
 communication is contrary to company policy and outside the scope of the 
 employment of the individual concerned. The company will not accept any 
 liability in respect of such communication, and the employee responsible will 
 be personally liable for any damages or other liability arising. This email 
 and any files transmitted with it are confidential and intended solely for 
 the use of the individual or entity to whom they are addressed. If you have 
 received this email in error please notify the system manager.-Original 
 Message-
 From: Hudson (JIRA) [mailto:j...@apache.org]
 Sent: 26 July 2010 12:13
 To: comm...@wicket.apache.org
 Subject: [jira] Commented: (WICKET-2967) org.apache.wicket.util.value.Count: 
 add decrement method


    [ 
 https://issues.apache.org/jira/browse/WICKET-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12892262#action_12892262
  ]

 Hudson commented on WICKET-2967:
 

 Integrated in Apache Wicket 1.4.x #62 (See 
 [http://hudson.zones.apache.org/hudson/job/Apache%20Wicket%201.4.x/62/])
    fixed: org.apache.wicket.util.value.Count: add decrement method
 Issue: WICKET-2967


 org.apache.wicket.util.value.Count: add decrement method
 

                 Key: WICKET-2967
                 URL: https://issues.apache.org/jira/browse/WICKET-2967
             Project: Wicket
          Issue Type: Wish
          Components: wicket
    Affects Versions: 1.4.9
            Reporter: Ralf Eichinger
            Assignee: Juergen Donnerstag
            Priority: Trivial
             Fix For: 1.4.10, 1.5-M1

   Original Estimate: 0.17h
  Remaining Estimate: 0.17h

 Wicket-Examples (LinkPage) use examples specific ClickCount-model class.
 Should use org.apache.wicket.util.value.Count class (to promote the use of 
 it).
 For being usable for all examples, the Count-class needs this additional 
 method:
 /**
  * Decreases the count value by one.
  */
 public void decrement() {
   count--;
 }
 and a setCount(int count) method.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.


 

 This footnote confirms that this email message has been swept by MIMEsweeper 
 for the presence of computer viruses.

 Bright Purple Resourcing Ltd is a company registered in Scotland with company 
 number SC155147. VAT Number 658 2716 10.
 Registered office address: Eagle Building, 19 Rose Street, Edinburgh. EH2 2PR
 www.brightpurple.co.uk

Re: Examples for the new request mappers

[Martin Makundi]

Hi M! Is was there a tutorial on this topic?

**
Martin

2010/7/24 Martin Grigorov mgrigo...@apache.org:
 Hi,

 I just added a new wicket-examples application (Wicket 1.5 only) showing two
 custom request mappers:
 * custom home page - e.g. requesting http://example.com will load
 Application#getHomePage() at http://example.com/custom/path
 * locale first mapper - the session locale is encoded as first segment in
 the url. This feature is often asked in the mailing lists and I used the
 mapper Igor posted about a year ago in the mailing lists.

 The examples will be visible at http://wicketstuff.org/wicket/ after the
 next deploy of the snapshot.

 If you have ideas for more examples with the new request mappers now is the
 moment to share them ;-)

 martin-g

Re: Examples for the new request mappers

[Martin Makundi]

Any brief what this is all about ;) ? Sounds interesting but I don't
have any clue. Any selected links to previous discussion on the topic?

**
Martin

2010/7/24 Martin Grigorov mgrigo...@apache.org:
 For now the only tutorial is the source code :-/

 On Sat, Jul 24, 2010 at 8:47 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Hi M! Is was there a tutorial on this topic?

 **
 Martin

 2010/7/24 Martin Grigorov mgrigo...@apache.org:
  Hi,
 
  I just added a new wicket-examples application (Wicket 1.5 only) showing
 two
  custom request mappers:
  * custom home page - e.g. requesting http://example.com will load
  Application#getHomePage() at http://example.com/custom/path
  * locale first mapper - the session locale is encoded as first segment in
  the url. This feature is often asked in the mailing lists and I used the
  mapper Igor posted about a year ago in the mailing lists.
 
  The examples will be visible at http://wicketstuff.org/wicket/ after the
  next deploy of the snapshot.
 
  If you have ideas for more examples with the new request mappers now is
 the
  moment to share them ;-)
 
  martin-g
 

Re: Igor did it!

[Martin Makundi]

Now there is time for RFEs ;) ?

2010/3/2 Matej Knopp matej.kn...@gmail.com:
 All tests in Wicket Trunk pass (except that one ignored, whatever that is).
 Kudos to Igor!

 -Matej

Re: Igor did it!

[Martin Makundi]

Yeah.. someone went and localized the h:mm(a---) in java some time
ago whose results are surprising. I am not completely convinced it (a)
should be locale-specific (am/pm).

In my opinnion the expected is wrong here, but on the other hand I am
not a linguist: http://bugs.sun.com/view_bug.do?bug_id=6610748

**
Martin

2010/3/2 Major Péter majorpe...@sch.bme.hu:
 Hi,

 Just for fun, I checked what's the last test, which fails
 (testSimpleStaticTimeFrame). After some debugging I found out, that when
 you creates timeFormat in org.apache.wicket.util.time.AbstractTime, then
 you don't specify the Locale, so when you call setCalendar with
 Locale.ENGLISH and parse in the testcase, then the formatter is still
 running under the OS locale (in my case HU), and it tries to parse the
 'h.mma' format in it, but it fails, because this is not a valid format
 in my locale.
 So this is the source of the problem, now you need to only fix it. :)
 (Or maybe remove the testcase if it's too specific?)

 Regards,
 Peter


 2010-03-02 12:40 keltezéssel, Matej Knopp írta:
 All tests in Wicket Trunk pass (except that one ignored, whatever that is).
 Kudos to Igor!

 -Matej

Re: Doubt about form components

[Martin Makundi]

Yes.. don't use referenceToModel. Instead call

textField.getDefaultModelObject();

**
Martin

2010/2/23 Pedro Santos pedros...@gmail.com:
 Hi Martin, consider this form:

 java code:
        Form form = new Form(form);
        add(form);
        final TextFieldInteger textField = new TextField(tf, new
 Model());
        textField.setType(Integer.class);
        textField.setOutputMarkupId(true);
        form.add(textField);
        AjaxLink link = new AjaxLink(reload) {
            public void onClick(AjaxRequestTarget target) {
                IModel referenceToModel = textField.getDefaultModel();
                referenceToModel.setObject(new Integer(30));
                target.addComponent(textField);
            }};
        form.add(link);
        form.add(new FeedbackPanel(fp));

 markup code:

 form wicket:id=form 
 input wicket:id=tf type=text /
 a wicket:id=reloadreload/a
 input type=submit /
 div wicket:id=fp /div
 /form

 In the browser:
 1 - you type something wrong on the text field, like some non numeric
 characters
 2 - submit the form. At this moment, you has your forms components on the
 server with the raw input
 3 - press reload link, to change the value on the text field model
 4 - you has now an text field presenting the wrong user typed value, and the
 new one on the component model on server.


 On Mon, Feb 22, 2010 at 5:55 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Hi!

 What's the difference whether it's thrown away or not if the next step
 is re-submit with new values?

 **
 Martin

 2010/2/22 Pedro Santos pedros...@gmail.com:
  IMO the form processing can be:
 
 
  1. validate
  2. detect error
  3. keep rawinput
  4. re-render error components with red border AND rawinput
 
 
  4.1. throw away the raw input in some detach method
 
  5. user retry form submit
 
 
  6. all form components get they raw input again since they get rendered
  before some detach method clear they raw input, no need to maintain those
  values on the server
 
 
 
 
  --
  Pedro Henrique Oliveira dos Santos
 




 --
 Pedro Henrique Oliveira dos Santos

Re: Doubt about form components

[Martin Makundi]

Hi!

 Hi, the form component clearInput method that clean this state is called on
 the valid method. I'm trying to guess why the form component keep his raw
 input after an form processing with errors.  I can't figure out why don't
 clear the raw input in this situation, since on the next form submit the raw
 input will to be updated any way.

I don't know the original design but if you (e.g., ajax) redraw some
components it's goddamn useful to have the raw input. Say that you
redraw erroneous components with red border like I do. You would lose
the raw value if you clear that and the user would lose the input.

 3 - the user perform some ajax work that update some form components model
 objects, and add then to the response.

If you chaneg model value you should call setmodelobject which clears
raw input (note: only if model really changes)!

**
Martin


 --
 Pedro Henrique Oliveira dos Santos

Re: Doubt about form components

[Martin Makundi]

Hi!

 I don't know the original design but if you (e.g., ajax) redraw some
 components it's goddamn useful to have the raw input. Say that you
 redraw erroneous components with red border like I do. You would lose
 the raw value if you clear that and the user would lose the input.

 Actually this statement make sense if you are telling me: is very useful
 keep the raw input during all rendering process. After render parse, I can't
 see any good reason to maintain the raw input.

I must elaborate:

1. validate
2. detect error
3. keep rawinput
4. re-render error components with red border AND rawinput
5. user retry form submit

 If you chaneg model value you should call setmodelobject which clears
 raw input (note: only if model really changes)!

 Consider that the user can use the same model instance on more than one
 component. Or that he can have controllers that only keep reference to the
 model.

Well.. then you just call clearinput yourself or implement a wrapped
model with something happening when it changes...

... or maybe the gurus here have even better suggestions for your special case.

**
Martin

Re: Doubt about form components

[Martin Makundi]

Hi!

What's the difference whether it's thrown away or not if the next step
is re-submit with new values?

**
Martin

2010/2/22 Pedro Santos pedros...@gmail.com:
 IMO the form processing can be:


 1. validate
 2. detect error
 3. keep rawinput
 4. re-render error components with red border AND rawinput


 4.1. throw away the raw input in some detach method

 5. user retry form submit


 6. all form components get they raw input again since they get rendered
 before some detach method clear they raw input, no need to maintain those
 values on the server




 --
 Pedro Henrique Oliveira dos Santos

Re: Patch for easy Enums I18N

[Martin Makundi]

I vote for EnumChoiceRender instead of full DropDownChoice.

However. EnumChoiceRenderer can render any TYPE so that's why I have
proposed TypeChoiceRenderer. You can directly use it with existing
wicket and no need for specific dropdown.

**
Martin

2009/11/11 Olivier Croisier olivier.crois...@gmail.com:
 Hi,

 I just submitted a patch to the very old
 WICKET-1157https://issues.apache.org/jira/browse/WICKET-1157JIRA (no
 activity for the last 2 years).
 It provides a simple and flexible way to internationalize enums :
 - An EnumMessageKeyProvided that implements a Strategy pattern to generate
 I18N keys from enums.
 - An EnumDropDownChoice to render HTML select components
 - An EnumModel to internationalize any enum provided by another Model (so
 there is no need of EnumLabels and such).

 Hope that helps,

 Olivier

Re: Patch for easy Enums I18N

[Martin Makundi]

 I admit the EnumDropDownChoice is more of a convenient class that a
 real new feature.

It's simply an overkill for the purpose. I loved the idea of a
TypeChoiceModel, though. Maybe it should also be tuned to be non
enum-specific, like the TypeChoiceRenderer.

 A standalone EnumChoiceRenderer would need to take a Component as a
 constructor parameter, to call getString() on,

This is not true. Localizer is available everywhere.

Application.get().getResourceSettings().getLocalizer();


**
Martin




 On Wed, Nov 11, 2009 at 7:58 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 I vote for EnumChoiceRender instead of full DropDownChoice.

 However. EnumChoiceRenderer can render any TYPE so that's why I have
 proposed TypeChoiceRenderer. You can directly use it with existing
 wicket and no need for specific dropdown.

 **
 Martin

 2009/11/11 Olivier Croisier olivier.crois...@gmail.com:
  Hi,
 
  I just submitted a patch to the very old
  WICKET-1157https://issues.apache.org/jira/browse/WICKET-1157JIRA (no
  activity for the last 2 years).
  It provides a simple and flexible way to internationalize enums :
  - An EnumMessageKeyProvided that implements a Strategy pattern to
 generate
  I18N keys from enums.
  - An EnumDropDownChoice to render HTML select components
  - An EnumModel to internationalize any enum provided by another Model (so
  there is no need of EnumLabels and such).
 
  Hope that helps,
 
  Olivier
 

Re: Patch for easy Enums I18N

[Martin Makundi]

Component is optional so it can be given optionally to the renderer.

I have attached a patch. However, it should still be coupled with
TypeChoiceModel so that they fetch the localized label using the same
method. I uploaded that too.

I also provided factory methods so that it is easier to construct these objects.

**
Martin

2009/11/12 Olivier Croisier olivier.crois...@gmail.com:
 The Localizer methods also require a Component as a parameter, so we're back
 to square one : we must provide a Component.
 Also, it would be helpful if you provided your alternative implementation as
 a well-formed patch instead of plain-text code in the Jira comment.


 On Wed, Nov 11, 2009 at 8:44 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  I admit the EnumDropDownChoice is more of a convenient class that a
  real new feature.

 It's simply an overkill for the purpose. I loved the idea of a
 TypeChoiceModel, though. Maybe it should also be tuned to be non
 enum-specific, like the TypeChoiceRenderer.

  A standalone EnumChoiceRenderer would need to take a Component as a
  constructor parameter, to call getString() on,

 This is not true. Localizer is available everywhere.

 Application.get().getResourceSettings().getLocalizer();


 **
 Martin
 
 
 
 
  On Wed, Nov 11, 2009 at 7:58 PM, Martin Makundi 
  martin.maku...@koodaripalvelut.com wrote:
 
  I vote for EnumChoiceRender instead of full DropDownChoice.
 
  However. EnumChoiceRenderer can render any TYPE so that's why I have
  proposed TypeChoiceRenderer. You can directly use it with existing
  wicket and no need for specific dropdown.
 
  **
  Martin
 
  2009/11/11 Olivier Croisier olivier.crois...@gmail.com:
   Hi,
  
   I just submitted a patch to the very old
   WICKET-1157https://issues.apache.org/jira/browse/WICKET-1157JIRA
 (no
   activity for the last 2 years).
   It provides a simple and flexible way to internationalize enums :
   - An EnumMessageKeyProvided that implements a Strategy pattern to
  generate
   I18N keys from enums.
   - An EnumDropDownChoice to render HTML select components
   - An EnumModel to internationalize any enum provided by another Model
 (so
   there is no need of EnumLabels and such).
  
   Hope that helps,
  
   Olivier
  
 
 

Re: Problem with IFormsubmitting

[Martin Makundi]

Hi!

The proposed solution does not work with Modal Windows!!
* http://osdir.com/ml/users-wicket.apache.org/2009-11/msg00076.html

Modal windws have a fake parent form:

form style=border-width: 0px; margin: 0px; padding: 0px;
background-color: transparent; position: static;

.. and ofcourse it does not have a hidden input field...

.. so the solution gets a bit nastier...

.. we must fake the hidden field value into the request ... ?

Is there another less pervasive way to do this? Maybe alter wicket a bit ;) ?

The solution here is implementation specific and probably works with jetty only:


public abstract class
AjaxFormSubmittingChangeListenerDropDownChoiceT extends
DropDownChoiceT {
  private final static Method hiddenFieldGetter;
  static {
try {
  hiddenFieldGetter = Form.class.getDeclaredMethod(getHiddenFieldId);
  hiddenFieldGetter.setAccessible(true);
} catch (Exception e) {
  throw new RuntimeException(e);
}
  }

  /** Initialize */ {
add(new AjaxFormSubmitBehavior(JavaScriptConstants.ONCHANGE) {

  @Override
  protected void onError(AjaxRequestTarget target) {
AjaxFormSubmittingChangeListenerDropDownChoice.this.onError(target);
  }

  @Override
  protected void onSubmit(AjaxRequestTarget target) {
AjaxFormSubmittingChangeListenerDropDownChoice.this.onSubmit(target);
  }

  /**
   * @see 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onEvent(org.apache.wicket.ajax.AjaxRequestTarget)
   */
  @Override
  protected void onEvent(AjaxRequestTarget target) {
org.mortbay.util.MultiMap parameters =
((org.mortbay.jetty.Request) ((WebRequest)
getRequest()).getHttpServletRequest()).getParameters();

parameters.put(getHiddenFieldId(AjaxFormSubmittingChangeListenerDropDownChoice.this.getForm()),

AjaxFormSubmittingChangeListenerDropDownChoice.this.urlFor(IOnChangeListener.INTERFACE));
super.onEvent(target);
  }

  /**
   * @param form
   * @return String
   */
  private String getHiddenFieldId(Form? form) {
try {
  Form? root = form.getRootForm();
  return (String) hiddenFieldGetter.invoke(root);
} catch (Exception e) {
  throw new RuntimeException(e);
}
  }

});
  }
}


**
Martin

 2009/11/4 Jeremy Thomerson jer...@wickettraining.com:
 The power of this list is amazing - it seems you just had an entire thread
 with yourself and answered your own question.  SYNERGY!  :)

 But seriously, did you have any remaining questions on this that we could
 assist with?


 --
 Jeremy Thomerson
 http://www.wickettraining.com

New behavior: AjaxFormSubmittingChangeListenerBehavior

[Martin Makundi]

Hi!

Here is the final solution. The behavior enables ajax FormSubmitting
component without default form processing (i.e., analogous to
IOnChangeListener). I hope I got it right because that's what I need
;)

I created a jira issue
(https://issues.apache.org/jira/browse/WICKET-2562) proposing to
overcome the reflection hacks:

public abstract class AjaxFormSubmittingChangeListenerBehavior extends
AjaxFormSubmitBehavior {
  private final static Method hiddenFieldGetter;
  static {
try {
  hiddenFieldGetter = Form.class.getDeclaredMethod(getHiddenFieldId);
  hiddenFieldGetter.setAccessible(true);
} catch (Exception e) {
  throw new RuntimeException(e);
}
  }

  /**
   * @see org.apache.wicket.ajax.AbstractDefaultAjaxBehavior#onBind()
   */
  @Override
  protected void onBind() {
super.onBind();

if (!(getComponent() instanceof IOnChangeListener))
{
  throw new WicketRuntimeException(Behavior  + getClass().getName() +
 can only be added to an instance of a IOnChangeListener);
}
  }

  /**
   * @param event
   */
  public AjaxFormSubmittingChangeListenerBehavior(String event) {
super(event);
  }

  /**
   * @see 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onError(org.apache.wicket.ajax.AjaxRequestTarget)
   */
  @Override
  protected void onError(AjaxRequestTarget target) {
onSubmit(target);
  }

  /**
   * @see 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onEvent(org.apache.wicket.ajax.AjaxRequestTarget)
   */
  @Override
  protected void onEvent(AjaxRequestTarget target) {
org.mortbay.util.MultiMap parameters =
((org.mortbay.jetty.Request) ((WebRequest) getComponent()
.getRequest()).getHttpServletRequest()).getParameters();
parameters.put(getHiddenFieldId(getForm()),
getComponent().urlFor(IOnChangeListener.INTERFACE));
super.onEvent(target);
  }

  /**
   * @param form
   * @return String
   */
  private String getHiddenFieldId(Form? form) {
try {
  Form? root = form.getRootForm();
  return (String) hiddenFieldGetter.invoke(root);
} catch (Exception e) {
  throw new RuntimeException(e);
}
  }
}

**
Martin

2009/11/4 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 The proposed solution does not work with Modal Windows!!
 * http://osdir.com/ml/users-wicket.apache.org/2009-11/msg00076.html

 Modal windws have a fake parent form:

 form style=border-width: 0px; margin: 0px; padding: 0px;
 background-color: transparent; position: static;

 .. and ofcourse it does not have a hidden input field...

 .. so the solution gets a bit nastier...

 .. we must fake the hidden field value into the request ... ?

 Is there another less pervasive way to do this? Maybe alter wicket a bit ;) ?

 The solution here is implementation specific and probably works with jetty 
 only:


 public abstract class
 AjaxFormSubmittingChangeListenerDropDownChoiceT extends
 DropDownChoiceT {
  private final static Method hiddenFieldGetter;
  static {
    try {
      hiddenFieldGetter = Form.class.getDeclaredMethod(getHiddenFieldId);
      hiddenFieldGetter.setAccessible(true);
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }

  /** Initialize */ {
    add(new AjaxFormSubmitBehavior(JavaScriptConstants.ONCHANGE) {

     �...@override
      protected void onError(AjaxRequestTarget target) {
        AjaxFormSubmittingChangeListenerDropDownChoice.this.onError(target);
      }

     �...@override
      protected void onSubmit(AjaxRequestTarget target) {
        AjaxFormSubmittingChangeListenerDropDownChoice.this.onSubmit(target);
      }

      /**
       * @see 
 org.apache.wicket.ajax.form.AjaxFormSubmitBehavior#onEvent(org.apache.wicket.ajax.AjaxRequestTarget)
       */
     �...@override
      protected void onEvent(AjaxRequestTarget target) {
        org.mortbay.util.MultiMap parameters =
 ((org.mortbay.jetty.Request) ((WebRequest)
 getRequest()).getHttpServletRequest()).getParameters();
        
 parameters.put(getHiddenFieldId(AjaxFormSubmittingChangeListenerDropDownChoice.this.getForm()),
            
 AjaxFormSubmittingChangeListenerDropDownChoice.this.urlFor(IOnChangeListener.INTERFACE));
        super.onEvent(target);
      }

      /**
       * @param form
       * @return String
       */
      private String getHiddenFieldId(Form? form) {
        try {
          Form? root = form.getRootForm();
          return (String) hiddenFieldGetter.invoke(root);
        } catch (Exception e) {
          throw new RuntimeException(e);
        }
      }

    });
  }
 }


 **
 Martin

 2009/11/4 Jeremy Thomerson jer...@wickettraining.com:
 The power of this list is amazing - it seems you just had an entire thread
 with yourself and answered your own question.  SYNERGY!  :)

 But seriously, did you have any remaining questions on this that we could
 assist with?


 --
 Jeremy Thomerson
 http://www.wickettraining.com

Re: Commit quickfix WICKET-2522?

[Martin Makundi]

Patch and junit test attached to jira. Hope it doesn't break anything...

**
Martin

2009/10/14 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!

 Would anybody with commit rights wanna commit one-liner fix + attached
 unit tests for https://issues.apache.org/jira/browse/WICKET-2522

 **
 Martin

Commit quickfix WICKET-2522?

[Martin Makundi]

Hi!

Would anybody with commit rights wanna commit one-liner fix + attached
unit tests for https://issues.apache.org/jira/browse/WICKET-2522

**
Martin

Re: True?

[Martin Makundi]

Here it was:

http://techblog.molindo.at/2009/09/wicketstuff-merged-resources-new-much-simpler-version.html

2009/10/14 Jeremy Thomerson jer...@wickettraining.com:
 Me either.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Wed, Oct 14, 2009 at 12:52 PM, Matej Knopp matej.kn...@gmail.com wrote:

 Don't know anything about it.

 Anyone else?

 -Matej

 On Wed, Oct 14, 2009 at 7:47 PM, Martin Funk mafulaf...@googlemail.com
 wrote:
  http://twitter.com/mraible/status/4860957884
 

Re: taking the I out of Interface

[Martin Makundi]

+1 data proxy or model proxy or proxymodel or wrapper model

2009/10/4 Jeremy Thomerson jer...@wickettraining.com:
 On Sun, Oct 4, 2009 at 8:45 AM, Matej Knopp matej.kn...@gmail.com wrote:

 Should we rename IModel to Model we would also have to rename Model to
 something. ObjectModel sounds like a really good name to me because it
 says what it does. Holds single object.

 Locator sounds really weird. I think renaming Model to Locator would
 be hell lot more confusing than renaming IModel to Model.



 I think he meant rename IModel to Locator.  I think that Locator or
 DataProxy or something more accurately describes it (nobody ever understands
 IModel right off the bat).  But I don't think changing it is worth the costs
 it would incur.

 --
 Jeremy Thomerson
 http://www.wickettraining.com

Re: taking the I out of Interface

[Martin Makundi]

-1

If it ain't broken, don't try to fix it.

**
Martin

Re: taking the I out of Interface

[Martin Makundi]

Well.. if it runs it ain't broken. But ofcourse if we want to refactor
just for the sake of arts, why the hell not!

**
Martin

2009/10/3 Matej Knopp matej.kn...@gmail.com:
 If it ain't broken, don't try to fix it.

 The thing here is that not all of us agree that it ain't broken.

 -Matej

Re: taking the I out of Interface

[Martin Makundi]

I am also curious how much more difficult it will make to switch from
1.4 to 1.5. The cost of renaming according to some fasion might
accumulate to millions of dollars in worldwide development teams. Just
for the sake of some damn another naming gimmic which does not bring
any real functionality (no value trade off for the money spent).

**
Martin

Re: taking the I out of Interface

[Martin Makundi]

Ok, that's a good answer. If this is true, I will vote for what ever
makes the artists happy.

**
Martin

2009/10/3 Matej Knopp matej.kn...@gmail.com:
 Oh come one. There are like 5 interfaces in Wicket prefixed with I
 that projects normally use. Couple of search and replace will
 certainly not bankrupt anyone.

 -Matej

 On Sat, Oct 3, 2009 at 10:51 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 I am also curious how much more difficult it will make to switch from
 1.4 to 1.5. The cost of renaming according to some fasion might
 accumulate to millions of dollars in worldwide development teams. Just
 for the sake of some damn another naming gimmic which does not bring
 any real functionality (no value trade off for the money spent).

 **
 Martin

Re: taking the I out of Interface

[Martin Makundi]

Very good point. I am worried that changing the i will only make
some very few core develoeprs or newcomers slightly bit happier until
they forget about that new thang.

**
Martin

2009/10/3 James Carman jcar...@carmanconsulting.com:
 For the record, I'm -1 also (non-binding of course).  We have to be
 careful here.  Tapestry got a bad reputation for changing things way
 too much between major revisions and leaving their users out in the
 cold.  It's one of the reasons I'm in the Wicket World these days.
 By no means do I want to stifle innovation or anything, but breaking
 compatibility should come with a rather big value-add.  In this case,
 I agree that the I is ugly and I actually hate it, but how much is
 it actually going to improve a Wicket user's day-to-day coding with
 Wicket.  Is it going to save hundreds of lines of code?  Is it going
 to save 20 minutes of development time per day?

 On Sat, Oct 3, 2009 at 5:02 AM, Matej Knopp matej.kn...@gmail.com wrote:
 Anyhow, this doesn't look like lot of people are in favor of dropping
 I. In that case we should make sure that *all* interfaces in 1.5 are
 prefixed in I. If we go the (imho) ugly and non conventional way then
 we should at least be consistent.

 -Matej

 On Sat, Oct 3, 2009 at 12:28 AM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 is it perhaps time to take the I out of our interface names? wicket
 has been the only project i have ever worked on/used that follows this
 convention, is it time for a change?

 this is not meant as a flamewar about which convention is teh
 aw3s0m3st, simply a discussion of whether or not we should switch.

 -igor

Re: Problem with Required component message

[Martin Makundi]

 I did this by creating a properties file MyPanel.properties and then setting
 creditCardForm.ccNumber.Required=Please enter your credit card number.
 Did you try setting form.componentId.Required? Or even 
 panel.form.componentId.Required

The problem is that my field is on a ListView. I cannot PREDICT the
INDEX!!! It will be: form.listview.*random_index*.componentId.Required

In my opinnion there is a bug in the stringResource-finder. It should
FIRST scan down the path before trying the Key=Required alone. Now it
tries the full path first, then Key=Required and if that is not found,
then it tries the next path depth.

 https://issues.apache.org/jira/browse/WICKET-2350

That's something different. I had a look at the HEAD Wicket svn, this
part of the code still remains:

// First, try the fully qualified resource name relative to the
// component on the path from page down.
... proper code here but FULLY QUALIFIED RESOURCE
Then right after that:

// If not found, than check if a property with the 'key' provided by
// the user can be found.
if ((string == null)  old)
{
string = loadStringResource(clazz, key, locale, 
style);
}

It looks for the key...Required. I.e., it will override with the default one.

In my opinnion the above block if not found... should be right after
the LOOP for (int i = searchStack.size() - 1; (i = 0)  (string ==
null); i--) and NOT WITHIN the loop as it is now.

**
Martin


 Russ
 Date: Sun, 2 Aug 2009 12:19:40 +0300
 Subject: Problem with Required component message
 From: martin.maku...@koodaripalvelut.com
 To: us...@wicket.apache.org

 Hi!

 I have a page with some required fields among which there is one
 specific field I want to return a specific required validation error
 message, if value not given.

 I have tried to put componentId.Required=Unique error message into
 Application.properties but it does not work. Instead Wicket always
 returns the standard Required error.

 Debugging deeper into the problem shows that Wicket constructs a
 dot-notation component path of the requied component:
 page.panel.form.nested_panel.listview.index.componentId.Required and
 tries to look for a property with such name. If not found, it next
 tries to look for Required alone and if it is found, it returns that
 (if Required was not found, it would continue dropping one prefix at a
 time until it would reach the assumed componentId.Required).

 This code is in:
 ComponentStringResourceLoader.loadStringResource(final Component
 component, final String key)

 Is there a flaw in the logic or am I doing something wrong here?

 **
 Martin

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 _
 Get back to school stuff for them and cashback for you.
 http://www.bing.com/cashback?form=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1

Bug in modal window.onBeforeRender - tests

[Martin Makundi]

Hi!

For some reason ModalWindow assumes request is not ajax even though it
is clicked via executeAjaxEvent:
if (getWebRequest().isAjax() == false)
{
shown = false; // This hides the button
}

Thread [main] (Suspended (breakpoint at line 3191 in Component))
SettingsModalPanelContents$8$3$1(Component).setVisible(boolean) line: 
3191  
ModalWindow.onBeforeRender() line: 820  
ModalWindow(Component).internalBeforeRender() line: 1061
ModalWindow(Component).beforeRender() line: 1095
RedirectPageRequestTarget(PageRequestTarget).respond(RequestCycle) 
line: 63 

WicketTester(MockWebApplication).postProcessRequestCycle(WebRequestCycle)
line: 558
WicketTester(MockWebApplication).processRequestCycle(WebRequestCycle)
line: 517
WicketTester(BaseWicketTester).executeAjaxEvent(Component, String) 
line: 1233   
WicketTester(BaseWicketTester).executeAjaxEvent(String, String) line: 
1109  
TestSettings.testModalSettings() line: 157  
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available   
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not 
available   
Method.invoke(Object, Object...) line: not available

So the test fails with no good reason when the modal window assumes it
is not visible.

Basically what the test does is the following:
1. submit form
2. click links
3. executeajaxevent
4. submit form
5. executeajaxevent to open modal window
6. exceuteajaxevent on a button on the modal window fails

I found a workaround by placing tester.setupRequestAndResponse()
just before line 5. Ofcourse a true fix would we nice.

**
Martin

Re: [VOTE] release wicket 1.4-rc6

[Martin Makundi]

[X] Yes release 1.4-rc6
[ ] No, don't release it


2009/6/30 Jeremy Thomerson jer...@wickettraining.com:
 [X] Yes release 1.4-rc6
 [ ] No, don't release it


 --
 Jeremy Thomerson
 http://www.wickettraining.com