Re: How to hide ListView rows the right way?

2010-11-09 Thread MattyDE

7zark7 i dont get your point. have you answered to the right thread?

any other hints?
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/How-to-hide-ListView-rows-the-right-way-tp3032125p3033271.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
Hi,

no offense meant, but the rhetoric in this thread is getting more and
more ridiculous. Chicken? Component hierarchy hell? Seriously? At
most maybe component hierarchy slight annoyance.

I am not at all convinced that this is a good idea. In my opinion, one
of the strongest and best points about Wicket is that it has a set of
very clear and logical concepts and does not deviate from them.
I especially like the fact that the truth is in the code and the code
rules, period. Unlike Tapestry, where you could pull all kinds of
stunts by using a special notation in the ID attributes of markup
elements.

The next thing is going to be that some developers don't want to touch
the code just because the designer wants a login panel on this other
page too. So why can't the designer write wicket:instantiate
class=foo/? It's just another hierarchy element, isn't it?

I frankly don't see any way to have this auto-hierarchy stuff
without getting lots of unnecessary ambiguity and sources of bugs. I
totally agree with what Eelco wrote below, and what someone else said
about the Python way of having only *one* way to do *one* thing.

The loss of predictability and clear concepts isn't worth the very
slight gain in... well, gain in what? In the ability to let code and
markup drift apart? To be honest, I don't even see the possible gain
with this change.

So far, I have often heard about people not liking the requirement to
match the code hierarchy in the markup. Most (not all!) of them have
never actually used Wicket (I know this doesn't apply to Martin). Not
once have I seen a convincing productive(!) example of where it was an
actual problem. In my current day-to-day work on a reasonably large
project, this hasn't come up *at all*. Not even in our sprint
retrospectives, where people are specifically asked to complain!

Carl-Eric
www.wicketbuch.de

On Tue, 9 Nov 2010 08:41:02 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Hi!
 
 Or should I say, boldly go where no man has gone before or Do, or
 do not. There is no 'try.' .
 
 **
 Martin
 
 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
  Chicken.
 
  2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com:
  But all really depends on your approach. Some people think
  dabbling in a swamp gives you a firm grip. I cosinder it the
  opposite: swamp has a firm grip on you.
 
  I consider it asking for trouble. Wicket would sacrifice
  predictability and conceptual surface for the sake of making a few
  things slightly less annoying. :-)
 
  Eelco
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 I frankly don't see any way to have this auto-hierarchy stuff
 without getting lots of unnecessary ambiguity and sources of bugs. I
 totally agree with what Eelco wrote below, and what someone else said
 about the Python way of having only *one* way to do *one* thing.

Would you be happy if there was an application level configuration switch:

  getMarkupSettings().setAllowComponentAutoHierarchy(true);

Which is default false?

This way you can make sure nobody in YOUR project messes things up?

**
Martin

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

 So far, I have often heard about people not liking the requirement to
 match the code hierarchy in the markup. Most (not all!) of them have
 never actually used Wicket (I know this doesn't apply to Martin). Not
 once have I seen a convincing productive(!) example of where it was an
 actual problem. In my current day-to-day work on a reasonably large
 project, this hasn't come up *at all*.

heree I can only ask you: Have you ever seen friction with your own eyes?

It's just the itchy feeling you get all day long when coding in the
zone. This unneccessary fuzz is in my way.

It might not be for everyone, but please don't deprive the needy ones.


**
Martin




 Carl-Eric
 www.wicketbuch.de

 On Tue, 9 Nov 2010 08:41:02 +0200
 Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Hi!

 Or should I say, boldly go where no man has gone before or Do, or
 do not. There is no 'try.' .

 **
 Martin

 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
  Chicken.
 
  2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com:
  But all really depends on your approach. Some people think
  dabbling in a swamp gives you a firm grip. I cosinder it the
  opposite: swamp has a firm grip on you.
 
  I consider it asking for trouble. Wicket would sacrifice
  predictability and conceptual surface for the sake of making a few
  things slightly less annoying. :-)
 
  Eelco
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

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


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 10:20:12 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

  I frankly don't see any way to have this auto-hierarchy stuff
  without getting lots of unnecessary ambiguity and sources of bugs. I
  totally agree with what Eelco wrote below, and what someone else
  said about the Python way of having only *one* way to do *one*
  thing.
 
 Would you be happy if there was an application level configuration
 switch:
 
   getMarkupSettings().setAllowComponentAutoHierarchy(true);

Possibly. I'd rather not have the unnecessary complexity of this
feature at all though. I certainly wouldn't want to support it if I was
a wicket developer :-)

 Which is default false?
 
 This way you can make sure nobody in YOUR project messes things up?

I have new projects every now and then, and most of them are already
underway when I get called in. Which is why I like toolkits that do not
encourage sloppiness(*).

Carl-Eric
www.wicketbuch.de


*) sloppiness != easy to write
   I'm all for static typing, since it saves me the work of checking
   the types. I'd like it to be more like Scala, which saves me the
   typing I have to do in Java, while still giving me the same
   guarantees. With your proposed config switch, you're basically
   giving up one of Wicket's guarantees, the one that the hierarchy is
   what it looks like in the code.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 10:23:27 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Hi!
 
  So far, I have often heard about people not liking the requirement
  to match the code hierarchy in the markup. Most (not all!) of them
  have never actually used Wicket (I know this doesn't apply to
  Martin). Not once have I seen a convincing productive(!) example of
  where it was an actual problem. In my current day-to-day work on a
  reasonably large project, this hasn't come up *at all*.
 
 heree I can only ask you: Have you ever seen friction with your own
 eyes?

Coding friction? Yes. Every time I need to look at somebody else's code
and try to figure out what exactly they did. And as a consultant (I
know, I said the nasty word) that is a pretty big part of what I do.
Please consider the needy ones that would have to deal with this and
would have to support people who made the mistake of using it :-)

 It's just the itchy feeling you get all day long when coding in the
 zone. This unneccessary fuzz is in my way.

If you only write code and never read or need to fix it.

 It might not be for everyone, but please don't deprive the needy ones.

Well that certainly applies the other way around too. It's not for
everybody, so please don't introduce a new source of bugs into *this*
toolkit. Also, unless I missed a message (which is possible), so far we
seem to have a needy *one*, not *ones*.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

 Coding friction? Yes. Every time I need to look at somebody else's code
 and try to figure out what exactly they did.

Ah.. so you are trying to solve your problem probably from the wrong
end? If you have bad warriors give them plastic swords so they can
hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies,
Dream teams, ...

 Please consider the needy ones that would have to deal with this and
 would have to support people who made the mistake of using it :-)

I don't think there is a substitute for coding skills/talent ;)))

 It's just the itchy feeling you get all day long when coding in the
 zone. This unneccessary fuzz is in my way.

 If you only write code and never read or need to fix it.

I understand if you are a consultant it gives you plenty of billable
to code again and again. But my sweetspot is product development and I
need to make flexibly reusable components and unfortunately requiring
html hierarchy to match on different pages makes really messy code on
java side if I try to implement free-from-iherarchy in a manual way (I
must provide various different parent containers to a generic
component so that it can land in the right place).

 Well that certainly applies the other way around too. It's not for
 everybody, so please don't introduce a new source of bugs into *this*
 toolkit. Also, unless I missed a message (which is possible), so far we
 seem to have a needy *one*, not *ones*.

Still, I don't think there is a substitute for coding skills/talent ;)))

**
Martin


 Carl-Eric
 www.wicketbuch.de

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



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



Wicket ajax-enabled enclosures

2010-11-09 Thread Martin Makundi
Hi!

Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ?

What I mean is that when I have:
wicket:enclosure child=optional-field
tr
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
/tr
/wicket

If I set it invisible via ajax I cannot set it visible again.

Instead, is there a way to do something like:


tr wicket:enclosure=child:optional-field
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
/tr

So that it would automatically handle visible/hidden
setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
element via ajax?

@See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/


**
Martin

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



Re: Configuration of AbstractCalendar

2010-11-09 Thread Jan Ferko

Thanks,

I figured it out. I have one more question ... can i use wicket 
behaviour to retrieve selected date from calendar or i have to write 
some JS hacks to do it?



On 11/06/2010 06:38 PM, Igor Vaynberg wrote:

i think its whatever format the yui component expects.

-igor

On Fri, Nov 5, 2010 at 9:25 AM, Jan Ferkojulyl...@gmail.com  wrote:
   

Hi,

Can anyone tell me what is format of map for
AbstractCalendar.configureWidgetProperties(Map map) ? For example I want to
set navigator property to true, but map.put(navigator, true) doesn't work.

thanks for answer
Jan

 

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

   



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



wicket 1.4.12 first time page visit

2010-11-09 Thread fachhoch

we noticed first time visit to the page is slow compared to next visits, we
are using wicket 1.4.12, is there anything I can do to improve performance.
 
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-12-first-time-page-visit-tp3034418p3034418.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
This is pretty much exactly what I'd do given such a requirement.

If something is so different as to require a different internal
hierarchy, it's no longer the same component. Make a new component and
use standard OO techniques for code reuse, like Frank wrote here.

This certainly is not worth the can of worms that's being opened right
now.

Carl-Eric
www.wicketbuch.de

On Tue, 9 Nov 2010 08:46:54 -0600
Frank Silbermann frank.silberm...@fedex.com wrote:

 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.
 
 Your constructor can call the component-creation methods to assemble
 the component hierarchy to match the HTML.
 
 Then, when you want a panel with a different hierarchy you subclass
 the panel, override the constructor to create the 2nd component
 hierarchy, and provide the new panel its own HTML page.
 
 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.
 
 /Frank
 
 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] 
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell
 
 Hi!
 
  Isn't this exactly the reason we've got CSS?
 
 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/
 
  HTML shouldn't really be used for lookfeel and the size and
  placement
 of
  components can perfectly be defined using CSS classes.
 
 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).
 
 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.
 
 **
 Martin
 
 
  Matt
 
  On 2010-11-09 13:34, Martin Makundi wrote:
 
  Also making skins for different devices / screen sizes becomes
 easier.
 
  **
  Martin
 
  2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:
 
  In simple cases it makes no difference. It makes real difference
 with
  some complex widgets (for example search components) that must be
  reused on many pages and they should render differently on each
 page
  depending on how much space and what context they are in. I don't
 like
  duplicating code even if it is gui code.
 
  Sounds like the first appealing argument slowly comming out of
  surrounding fuzz =)
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 


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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 14:21:46 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

Here we finally come to an actual argument about this:

 Panel is not reusable enough because it has its own markup. If I
 override its markup, it stops working.

Frank wrote in another message how to deal with this case. I agree with
him and add: If your new panel is so different from the old panel that
it requires a different internal hierarchy, it's no longer the same
component. Use standard OO techniques to deal with it. Also, think
about whether your component design (as in what parts form a component,
and what parts don't) is correct. Seems to me that in such a case too
many things have been thrown together that should not be together.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 11:01:28 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Hi!
 
  Coding friction? Yes. Every time I need to look at somebody else's
  code and try to figure out what exactly they did.
 
 Ah.. so you are trying to solve your problem probably from the wrong
 end? If you have bad warriors give them plastic swords so they can
 hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies,
 Dream teams, ...

So a clear architecture is a plastic sword? And do whatever you want
is better?

  Please consider the needy ones that would have to deal with this and
  would have to support people who made the mistake of using it :-)
 
 I don't think there is a substitute for coding skills/talent ;)))

There isn't. That's not the point. So far your argument seems to be #1
I don't like this and #2 those who don't agree with you aren't good
coders.

  It's just the itchy feeling you get all day long when coding in
  the zone. This unneccessary fuzz is in my way.
 
  If you only write code and never read or need to fix it.
 
 I understand if you are a consultant it gives you plenty of billable
 to code again and again.

WTF? Your argument #3 is that *I* want to screw my customers over?
Seriously?

 But my sweetspot is product development and I
 need to make flexibly reusable components and unfortunately requiring
 html hierarchy to match on different pages makes really messy code on
 java side if I try to implement free-from-iherarchy in a manual way (I
 must provide various different parent containers to a generic
 component so that it can land in the right place).

This just doesn't make sense. Put your stuff in a panel, then it's a
self-contained component and insulated from the hierarchy of the page
and other components. Then you can put that component wherever you want.

  Well that certainly applies the other way around too. It's not for
  everybody, so please don't introduce a new source of bugs into
  *this* toolkit. Also, unless I missed a message (which is
  possible), so far we seem to have a needy *one*, not *ones*.
 
 Still, I don't think there is a substitute for coding
 skills/talent ;)))

And I still haven't yet seen a convincing example of this being a
problem worth adding the complexity.

Then again, in the end the Wicket devs need to decide on whether they
want to support this or not. So far *my* definitely non-binding vote is
-1 :)

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Vitaly Tsaplin
 In simple cases it makes no difference. It makes real difference with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each page
 depending on how much space and what context they are in. I don't like
 duplicating code even if it is gui code.

Sounds like the first appealing argument slowly comming out of
surrounding fuzz =)

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Also making skins for different devices / screen sizes becomes easier.

**
Martin

2010/11/9 Vitaly Tsaplin vitaly.tsap...@gmail.com:
 In simple cases it makes no difference. It makes real difference with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each page
 depending on how much space and what context they are in. I don't like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

 Isn't this exactly the reason we've got CSS?

It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut it:
* http://blog.iconara.net/2007/09/21/the-failure-of-css/

 HTML shouldn't really be used for lookfeel and the size and placement of
 components can perfectly be defined using CSS classes.

In CSS the actual nesting of components plays a big role (div inside
float inside abs top 0px ul relative etc.).

If you want a professional finish, you will often need to pull
components around the layers for different display. Even trying to
pull one component will break wicket in strict hierarchy mode.

**
Martin


 Matt

 On 2010-11-09 13:34, Martin Makundi wrote:

 Also making skins for different devices / screen sizes becomes easier.

 **
 Martin

 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

 In simple cases it makes no difference. It makes real difference with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each page
 depending on how much space and what context they are in. I don't like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)




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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 your proposal is to wicket, what auto-generating-java-servlet-code is to a
 JSP (~ what a tied-and-deciding-designer-code was to a programmer-code
 in the past)

 that is, simply going back to hell :)

 why don't you stay on JSP domain, instead, sir?

Please have some patience, just watch and see what will come out of it.

You can decide for yourself whether to use it or not. Wicket community
can decide whether to keep the patch as wicket-stuff or wicket.

**
Martin


 On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller 
 matthias.kel...@ergon.chwrote:

 Hi Martin

 Isn't this exactly the reason we've got CSS?
 HTML shouldn't really be used for lookfeel and the size and placement of
 components can perfectly be defined using CSS classes.

 Matt


 On 2010-11-09 13:34, Martin Makundi wrote:

 Also making skins for different devices / screen sizes becomes easier.

 **
 Martin

 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

 In simple cases it makes no difference. It makes real difference with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each page
 depending on how much space and what context they are in. I don't like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)






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



RE: Free wicket from component hierarchy hell

2010-11-09 Thread Frank Silbermann
Well then, why don't you have your base panel provide methods that
generate the individual components, with methods that implement
composite behaviors involving groups of components.

Your constructor can call the component-creation methods to assemble the
component hierarchy to match the HTML.

Then, when you want a panel with a different hierarchy you subclass the
panel, override the constructor to create the 2nd component hierarchy,
and provide the new panel its own HTML page.

If you don't like overriding the constructor along with the HTML, then
you can build some sort of configurable constructor-constructor.

/Frank

-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] 
Sent: Tuesday, November 09, 2010 6:55 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

Hi!

 Isn't this exactly the reason we've got CSS?

It's just the buzz, not the reality. Unfortunately often CSS doesn't
quite cut it:
* http://blog.iconara.net/2007/09/21/the-failure-of-css/

 HTML shouldn't really be used for lookfeel and the size and placement
of
 components can perfectly be defined using CSS classes.

In CSS the actual nesting of components plays a big role (div inside
float inside abs top 0px ul relative etc.).

If you want a professional finish, you will often need to pull
components around the layers for different display. Even trying to
pull one component will break wicket in strict hierarchy mode.

**
Martin


 Matt

 On 2010-11-09 13:34, Martin Makundi wrote:

 Also making skins for different devices / screen sizes becomes
easier.

 **
 Martin

 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

 In simple cases it makes no difference. It makes real difference
with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each
page
 depending on how much space and what context they are in. I don't
like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)




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


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



Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread armandoxxx

Just to let everyone know, this is just a simple imeplementation, there are
no events triggered on draggable and therefore no methods called, so if
anyone needs it just implement it .. 
So all the NPE checks and that kinda  stuff is still needed ! 
All I needed for my case was to get the dropped component and I needed it to
be done with JQuery.

Regards

Armando



-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Wicket Training - London, Munich, Bangalore, Amsterdam, Brussels

2010-11-09 Thread Cemal Bayramoglu
Public Wicket courses for autumn/winter 2010 are scheduled as follows:

London [1]:
Jan8-9(Sat-Sun), Jan10-11(Mon-Tue), Feb5-6(Sat-Sun), Feb7-8(Mon-Tue)

Munich [1][2]:
Nov11-12(Thu-Fri), Q1 TBD

Amsterdam [1][3]:
Nov11-12(Thu-Fri), Q1/Q2 TBD

Bangalore [1]:
Q1/Q2 TBD

Brussels [3]
Q1/Q2 TBD

Please contact us [4] for any on-site/special content/date requirements.

Regards - Cemal
jWeekend
Training, Consulting, Development
http://jWeekend.com

[1] http://jweekend.com/dev/BookingPage
[2] http://comsysto.com/
[3] http://www.jteam.nl/training/apache-wicket-training.html
[4] http://jweekend.com/dev/ContactUs

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

 I don't think there is a substitute for coding skills/talent ;)))

 There isn't. That's not the point. So far your argument seems to be #1
 I don't like this and #2 those who don't agree with you aren't good
 coders.

Bad coding was your argument, not mine ;)

I simply don't allow bad coders into the equation.

 So a clear architecture is a plastic sword?

No, but if you don't facilitate certaint things it sort of takes the
edge off the blade ... child play stuff. You must prefer linux over
windows, eh? All those linked libraries ...

 This just doesn't make sense. Put your stuff in a panel, then it's a
 self-contained component and insulated from the hierarchy of the page
 and other components. Then you can put that component wherever you want.

Panel is not reusable enough because it has its own markup. If I
override its markup, it stops working.

 And I still haven't yet seen a convincing example of this being a
 problem worth adding the complexity.

In simple cases it makes no difference. It makes real difference with
some complex widgets (for example search components) that must be
reused on many pages and they should render differently on each page
depending on how much space and what context they are in. I don't like
duplicating code even if it is gui code.

**
Martin

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 10:05:39 -0500
James Carman ja...@carmanconsulting.com wrote:

 I think we need to try to put our heads together on this one.  I don't
 necessarily think this approach is the best, but I haven't really had
 a chance to wrap my head around it yet, frankly.  Do we really think
 this is that big of a problem that we need to change the whole
 paradigm of the framework to address it?  Perhaps you can create a new
 container component that does all of this stuff with some pre-render
 magic or something?  If you want to use it, you can.  If not, you
 don't have to.  So, if you're the type that likes this loosey goosey
 stuff, you basically wrap your pages with one of these things to
 enable this type of behavior.  I don't know.  This is just off the top
 of my head.  Still not done with my morning coffee.


+0.5

If this can be done with a special-case container
(HighlyDangerousLiquidHierarchyMarkupContainer ;-) ), I wouldn't really
mind, as long as the impact on the rest of the framework is small.

I do not think it's worth it to change the whole framework around this
special case. Especially since things like enabling/disabling of
components based on their parents in the hierarchy don't seem to have
been addressed yet.

Carl-Eric
www.wicketbuch.de

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



Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread Martin Makundi
Can it automatically detect which draggable dropped on droppable landing spot?

**
Martin

2010/11/9 armandoxxx armando@dropchop.com:

 Hey

 Just needed this so I wrote a simple implementation of Drag and Drop for
 JQuery javascript lib.

 So if anyone needs it .. be my guest to comment (and/or diSS) on it

 Put on your page, app or anywhere else cause you need this !!!

 wicket:head
 wicket:linklink rel=stylesheet type=text/css
 href=css/jquery/smoothness/jquery-ui-1.8.2.custom.css //wicket:link
                wicket:linkscript type=text/javascript
 src=js/jquery-1.4.3.min.js/script/wicket:link
                wicket:linkscript type=text/javascript
 src=js/jquery-ui-1.8.2.custom.min.js/script/wicket:link
 /wicket:head


 DraggableBehavior.java

 /**
  *
  */
 package org.dropchop.jop.dnd.behaviors.draggable;

 import java.util.HashMap;
 import java.util.Map;

 import org.apache.wicket.Component;
 import org.apache.wicket.behavior.AbstractAjaxBehavior;
 import org.apache.wicket.markup.html.CSSPackageResource;
 import org.apache.wicket.markup.html.IHeaderResponse;
 import org.apache.wicket.util.template.PackagedTextTemplate;
 import org.apache.wicket.util.template.TextTemplate;
 import org.dropchop.jop.dnd.behaviors.droppable.DroppableBehavior;


 /**
  * @author armando armando[DoT]ota[At]dropchop[DoT]com
  *
  */
 public class DraggableBehavior extends AbstractAjaxBehavior {

        private static final long serialVersionUID = -4879330165262306147L;

        //JQuery options
        private DragType dragType       = DragType.ORIGINAL;



        /**
         * Drag type for jQuery helper.
         * CLONE     - clones panel and after panel is droped cloned panel
 dissapears.
         * ORIGINAL  - moves the original panel through the page.
         * @author armando armando@dropchop.com
         */
        public enum DragType {
                ORIGINAL(original), CLONE(clone);

                private String type     = null;

                /**
                 * Private constructor.
                 * @param theType  jquery constant string
                 */
                private DragType(final String theType) {
                        this.type       = theType;
                }


                /**
                 * Gets JQuery drag type constant.
                 * @return string.
                 */
                public String getType() {
                        return this.type;
                }
        }


        /**
         * Sets drag type for draggable component
         * @param theType
         * @return  reference to itself for chaining.
         */
        public DraggableBehavior setDragType(final DragType theType) {
                this.dragType   = theType;
                return this;
        }


       �...@override
        public void renderHead(final IHeaderResponse theResponse) {
                super.renderHead(theResponse);

 theResponse.renderOnDomReadyJavascript(this.getJavaScriptCode(this.getComponent()));
        }


       �...@override
        protected void onBind() {
                getComponent().setOutputMarkupId(true);
                //uncomment this if you need styles for draggable component!

 //getComponent().add(CSSPackageResource.getHeaderContribution(DroppableBehavior.class,
 css/styles.css));
        }


        /**
         * Uses js file as a template and returns parsed output.
         *
         * @param theComponentId  id of date time field component.
         * @return javascript code string.
         *
         * Note: this might be a performance issue ... figure and test it 
 out!!!
         */
        private String getJavaScriptCode(final Component theComponent) {
                PackagedTextTemplate template = new 
 PackagedTextTemplate(getClass(),
 js/DraggableBehavior.js, text/javascript);
                MapString, Object params = new HashMapString, Object();
                params.put(componentId, theComponent.getMarkupId());
                params.put(helper, this.dragType.getType());
                params.put(wicketPath, theComponent.getPageRelativePath());
                TextTemplate interpolated = template.interpolate(params);
                return interpolated.asString();
        }


        /* (non-Javadoc)
         * @see org.apache.wicket.behavior.IBehaviorListener#onRequest()
         */
       �...@override
        public void onRequest() {}


 }




 DraggableBehavior.js  servers as a template for javascript code


 $(#${componentId}).draggable(
        {
                cursor          : 'pointer',
                helper          : '${helper}'
        }
 );
 $('#${componentId}').data('wicketPath', '${wicketPath}');



 DroppableBehavior.java

 package org.dropchop.jop.dnd.behaviors.droppable;

 import java.util.HashMap;
 import java.util.Map;

 import org.apache.wicket.Component;
 import org.apache.wicket.Request;
 import org.apache.wicket.RequestCycle;
 import 

Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread armandoxxx


/**
 * Notification method that a drop happened on this component.
 * @param theComponent  reference to dropped component.
 */
protected void onDrop(final AjaxRequestTarget theTarget, final Component
theComponent) {
System.out.println(Dropped: + 
theComponent.getClass().getName());
}


you get the draggable component that was dropped. 

Regards

Armando


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033686.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread manuelbarzi
your proposal is to wicket, what auto-generating-java-servlet-code is to a
JSP (~ what a tied-and-deciding-designer-code was to a programmer-code
in the past)

that is, simply going back to hell :)

why don't you stay on JSP domain, instead, sir?

On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller matthias.kel...@ergon.chwrote:

 Hi Martin

 Isn't this exactly the reason we've got CSS?
 HTML shouldn't really be used for lookfeel and the size and placement of
 components can perfectly be defined using CSS classes.

 Matt


 On 2010-11-09 13:34, Martin Makundi wrote:

 Also making skins for different devices / screen sizes becomes easier.

 **
 Martin

 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

 In simple cases it makes no difference. It makes real difference with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each page
 depending on how much space and what context they are in. I don't like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)






Re: Free wicket from component hierarchy hell

2010-11-09 Thread Matthias Keller

Hi Martin

Isn't this exactly the reason we've got CSS?
HTML shouldn't really be used for lookfeel and the size and placement 
of components can perfectly be defined using CSS classes.


Matt

On 2010-11-09 13:34, Martin Makundi wrote:

Also making skins for different devices / screen sizes becomes easier.

**
Martin

2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

In simple cases it makes no difference. It makes real difference with
some complex widgets (for example search components) that must be
reused on many pages and they should render differently on each page
depending on how much space and what context they are in. I don't like
duplicating code even if it is gui code.

Sounds like the first appealing argument slowly comming out of
surrounding fuzz =)





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
For what it's worth, I agree with these sentiments.  I am not jazzed
about this whole auto hierarchy idea.  I too like the predictability
of Wicket and I don't mind staying within the confines of a strict
hierarchy.  I've kept quiet until now because I really don't have the
time to jump into this debate whole-heartedly, but I wanted to at
least let my voice be heard as one who opposes such an idea.

On Tue, Nov 9, 2010 at 3:15 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
 Hi,

 no offense meant, but the rhetoric in this thread is getting more and
 more ridiculous. Chicken? Component hierarchy hell? Seriously? At
 most maybe component hierarchy slight annoyance.

 I am not at all convinced that this is a good idea. In my opinion, one
 of the strongest and best points about Wicket is that it has a set of
 very clear and logical concepts and does not deviate from them.
 I especially like the fact that the truth is in the code and the code
 rules, period. Unlike Tapestry, where you could pull all kinds of
 stunts by using a special notation in the ID attributes of markup
 elements.

 The next thing is going to be that some developers don't want to touch
 the code just because the designer wants a login panel on this other
 page too. So why can't the designer write wicket:instantiate
 class=foo/? It's just another hierarchy element, isn't it?

 I frankly don't see any way to have this auto-hierarchy stuff
 without getting lots of unnecessary ambiguity and sources of bugs. I
 totally agree with what Eelco wrote below, and what someone else said
 about the Python way of having only *one* way to do *one* thing.

 The loss of predictability and clear concepts isn't worth the very
 slight gain in... well, gain in what? In the ability to let code and
 markup drift apart? To be honest, I don't even see the possible gain
 with this change.

 So far, I have often heard about people not liking the requirement to
 match the code hierarchy in the markup. Most (not all!) of them have
 never actually used Wicket (I know this doesn't apply to Martin). Not
 once have I seen a convincing productive(!) example of where it was an
 actual problem. In my current day-to-day work on a reasonably large
 project, this hasn't come up *at all*. Not even in our sprint
 retrospectives, where people are specifically asked to complain!

 Carl-Eric
 www.wicketbuch.de

 On Tue, 9 Nov 2010 08:41:02 +0200
 Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Hi!

 Or should I say, boldly go where no man has gone before or Do, or
 do not. There is no 'try.' .

 **
 Martin

 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
  Chicken.
 
  2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com:
  But all really depends on your approach. Some people think
  dabbling in a swamp gives you a firm grip. I cosinder it the
  opposite: swamp has a firm grip on you.
 
  I consider it asking for trouble. Wicket would sacrifice
  predictability and conceptual surface for the sake of making a few
  things slightly less annoying. :-)
 
  Eelco
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

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


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 7:49 AM, manuelbarzi manuelba...@gmail.com wrote:
 why don't you stay on JSP domain, instead, sir?


Let's keep it civil here folks.  Can we agree to disagree without
being disagreeable?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread manuelbarzi
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...

On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 Can you see the matrix?

 ;)

 If you have:

 html
  form wicket:id=form
 input wicket:id=input .../
  /form
 /html

 public class MyPage extends WebPage {
public MyPage () {
   add(new Form(form));
   add(new TextField(input, model)); // Wicket could
 automatically handle parse hierarchy from markup
}
 }

 **
 Martin

 2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
  1. I want freedom inside panels.
 
  2. Doubly defined hierarhices are redundant. Server-side hierarchy can
  be automatically deduced from markup hierarcy. Such tasks should be
  done by COMPUTER. Not coder.
 
  **
  Martin
 
  2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
 
  I think if you find component hierarchies to be hell, you probably
 aren't
  using Wicket right. Break things down into small reusable chunks using
  Panels and you will find everything gets much, much easier.
  --
  View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

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




Wicket JQuery drag and drop behaviors

2010-11-09 Thread armandoxxx

Hey 

Just needed this so I wrote a simple implementation of Drag and Drop for
JQuery javascript lib. 

So if anyone needs it .. be my guest to comment (and/or diSS) on it  

Put on your page, app or anywhere else cause you need this !!!

wicket:head
wicket:linklink rel=stylesheet type=text/css
href=css/jquery/smoothness/jquery-ui-1.8.2.custom.css //wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-1.4.3.min.js/script/wicket:link
wicket:linkscript type=text/javascript
src=js/jquery-ui-1.8.2.custom.min.js/script/wicket:link
/wicket:head


DraggableBehavior.java

/**
 * 
 */
package org.dropchop.jop.dnd.behaviors.draggable;

import java.util.HashMap;
import java.util.Map;

import org.apache.wicket.Component;
import org.apache.wicket.behavior.AbstractAjaxBehavior;
import org.apache.wicket.markup.html.CSSPackageResource;
import org.apache.wicket.markup.html.IHeaderResponse;
import org.apache.wicket.util.template.PackagedTextTemplate;
import org.apache.wicket.util.template.TextTemplate;
import org.dropchop.jop.dnd.behaviors.droppable.DroppableBehavior;


/**
 * @author armando armando[DoT]ota[At]dropchop[DoT]com
 * 
 */
public class DraggableBehavior extends AbstractAjaxBehavior {

private static final long serialVersionUID = -4879330165262306147L;

//JQuery options
private DragType dragType   = DragType.ORIGINAL;



/**
 * Drag type for jQuery helper.
 * CLONE - clones panel and after panel is droped cloned panel
dissapears.
 * ORIGINAL  - moves the original panel through the page.
 * @author armando armando@dropchop.com
 */
public enum DragType {
ORIGINAL(original), CLONE(clone);

private String type = null;

/**
 * Private constructor.
 * @param theType  jquery constant string
 */
private DragType(final String theType) {
this.type   = theType;
} 


/**
 * Gets JQuery drag type constant.
 * @return string.
 */
public String getType() {
return this.type;
}
}


/**
 * Sets drag type for draggable component
 * @param theType
 * @return  reference to itself for chaining.
 */
public DraggableBehavior setDragType(final DragType theType) {
this.dragType   = theType;
return this;
}


@Override
public void renderHead(final IHeaderResponse theResponse) {
super.renderHead(theResponse);

theResponse.renderOnDomReadyJavascript(this.getJavaScriptCode(this.getComponent()));
} 


@Override
protected void onBind() {
getComponent().setOutputMarkupId(true);
//uncomment this if you need styles for draggable component!

//getComponent().add(CSSPackageResource.getHeaderContribution(DroppableBehavior.class,
css/styles.css));
}


/**
 * Uses js file as a template and returns parsed output.
 * 
 * @param theComponentId  id of date time field component.
 * @return javascript code string.
 * 
 * Note: this might be a performance issue ... figure and test it 
out!!! 
 */
private String getJavaScriptCode(final Component theComponent) {
PackagedTextTemplate template = new 
PackagedTextTemplate(getClass(),
js/DraggableBehavior.js, text/javascript);
MapString, Object params = new HashMapString, Object();
params.put(componentId, theComponent.getMarkupId());
params.put(helper, this.dragType.getType());
params.put(wicketPath, theComponent.getPageRelativePath());
TextTemplate interpolated = template.interpolate(params);
return interpolated.asString();
}


/* (non-Javadoc)
 * @see org.apache.wicket.behavior.IBehaviorListener#onRequest()
 */
@Override
public void onRequest() {}


}




DraggableBehavior.js  servers as a template for javascript code


$(#${componentId}).draggable(
{
cursor  : 'pointer',
helper  : '${helper}'
}
);
$('#${componentId}').data('wicketPath', '${wicketPath}');



DroppableBehavior.java

package org.dropchop.jop.dnd.behaviors.droppable;

import java.util.HashMap;
import java.util.Map;

import org.apache.wicket.Component;
import org.apache.wicket.Request;
import org.apache.wicket.RequestCycle;
import 

Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread armandoxxx

Hey guys .. 

10x for sharing .. 
Was looking for it .. but didn't find anything so I implemented it on my
own;) 

Regards

Armando


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3034347.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread julien roche AKA indiana_jules
Hi Armandoxxx,

If you want, you have too an implementation for your case with wiQuery (see:
http://wiquery-examples-1-1-x.appspot.com/?wicket:bookmarkablePage=:org.odlabs.wiquery.examples.droppable.DroppablePage).
But your approach is very ligthweight !!

Regards

Julien


On Tue, Nov 9, 2010 at 2:30 PM, armandoxxx armando@dropchop.com wrote:


 Just to let everyone know, this is just a simple imeplementation, there are
 no events triggered on draggable and therefore no methods called, so if
 anyone needs it just implement it ..
 So all the NPE checks and that kinda  stuff is still needed !
 All I needed for my case was to get the dropped component and I needed it
 to
 be done with JQuery.

 Regards

 Armando



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html
 Sent from the Users forum mailing list archive at Nabble.com.

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




RE: Free wicket from component hierarchy hell

2010-11-09 Thread Frank Silbermann
As an alternative, suppose that one's non-panel compound component
contained a map from wicket-id's to components.  The hierarchy could be
encoded in a lisp-like string; the component's constructor could parse
the string and create the component hierarchy to match.  The hierarchy
string could be a configuration property that the constructor looks up.

When you want to use the component on an HTML page whose wicket-ids are
embedded differently, set the configuration parameter to the desired
hierarchy string.

So instead of asking, How can we make Wicket different so that my
problem will go away? the proper question to try first is, What is the
Wicket way of solving my problem?

-Original Message-
From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] 
Sent: Tuesday, November 09, 2010 9:12 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

On Tue, 9 Nov 2010 14:21:46 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

Here we finally come to an actual argument about this:

 Panel is not reusable enough because it has its own markup. If I
 override its markup, it stops working.

Frank wrote in another message how to deal with this case. I agree with
him and add: If your new panel is so different from the old panel that
it requires a different internal hierarchy, it's no longer the same
component. Use standard OO techniques to deal with it. Also, think
about whether your component design (as in what parts form a component,
and what parts don't) is correct. Seems to me that in such a case too
many things have been thrown together that should not be together.

Carl-Eric
www.wicketbuch.de

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


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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.
 Your constructor can call the component-creation methods to assemble the
 component hierarchy to match the HTML.
 Then, when you want a panel with a different hierarchy you subclass the
 panel, override the constructor to create the 2nd component hierarchy,
 and provide the new panel its own HTML page.
 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.

That sounds really slick a good example of what we are trying to
avoid having to do.

**
Martin



 /Frank

 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 Hi!

 Isn't this exactly the reason we've got CSS?

 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/

 HTML shouldn't really be used for lookfeel and the size and placement
 of
 components can perfectly be defined using CSS classes.

 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).

 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.

 **
 Martin


 Matt

 On 2010-11-09 13:34, Martin Makundi wrote:

 Also making skins for different devices / screen sizes becomes
 easier.

 **
 Martin

 2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:

 In simple cases it makes no difference. It makes real difference
 with
 some complex widgets (for example search components) that must be
 reused on many pages and they should render differently on each
 page
 depending on how much space and what context they are in. I don't
 like
 duplicating code even if it is gui code.

 Sounds like the first appealing argument slowly comming out of
 surrounding fuzz =)




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


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 So instead of asking, How can we make Wicket different so that my
 problem will go away? the proper question to try first is, What is the
 Wicket way of solving my problem?

That's not how proggress is made...

**
Martin


 -Original Message-
 Fro

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Grigorov
I think we have to make a vote whether this feature has to be investigated
further.
There are over 90 mails in the thread and I have the feeling that only
Martin Makundi likes the idea.

On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com
 wrote:

 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.

 Your constructor can call the component-creation methods to assemble the
 component hierarchy to match the HTML.

 Then, when you want a panel with a different hierarchy you subclass the
 panel, override the constructor to create the 2nd component hierarchy,
 and provide the new panel its own HTML page.

 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.

 /Frank

 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 Hi!

  Isn't this exactly the reason we've got CSS?

 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/

  HTML shouldn't really be used for lookfeel and the size and placement
 of
  components can perfectly be defined using CSS classes.

 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).

 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.

 **
 Martin

 
  Matt
 
  On 2010-11-09 13:34, Martin Makundi wrote:
 
  Also making skins for different devices / screen sizes becomes
 easier.
 
  **
  Martin
 
  2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:
 
  In simple cases it makes no difference. It makes real difference
 with
  some complex widgets (for example search components) that must be
  reused on many pages and they should render differently on each
 page
  depending on how much space and what context they are in. I don't
 like
  duplicating code even if it is gui code.
 
  Sounds like the first appealing argument slowly comming out of
  surrounding fuzz =)
 
 
 

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


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




Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 10:23 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 That's not how proggress is made...


Well, it's at least a sane place to start.  Figuring out how Wicket
can be used as-is to solve your problem lets you know if it's really a
problem or not.  If this can be done in a non-intrusive way, then you
can just do it yourself and provide it as a wicketstuff module.  If
enough folks use it and say man, I really wish the core framework
worked like this, then perhaps we consider putting it into the core.

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



RE: Free wicket from component hierarchy hell

2010-11-09 Thread Frank Silbermann
Progress is made by people who have understanding, not by the ignorant.
You're not in a position to make suggestions about extending Wicket if
you don't yet understand how to use the powers it already has. 

-Original Message-
From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] 
Sent: Tuesday, November 09, 2010 9:23 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

 So instead of asking, How can we make Wicket different so that my
 problem will go away? the proper question to try first is, What is
the
 Wicket way of solving my problem?

That's not how proggress is made...

**
Martin



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



SV: Free wicket from component hierarchy hell

2010-11-09 Thread Wilhelmsen Tor Iver
 That's not how proggress is made...

No, but there are dozens of web frameworks, why try to progress Wicket into 
something that works in a way there perhaps already is another framework does? 
What you propose sounds close to how Tapestry already works, for instance...

- Tor Iver

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 That's not how proggress is made...

 Well, it's at least a sane place to start.  Figuring out how Wicket
 can be used as-is to solve your problem lets you know if it's really a 
 problem or not.

I've been dabbling with Wicket for 2,5 years now, and I have now
finally come up with this request for the core wicketeers to show us
the correct way to patch this particular issue.

I am very thankful for the very proactive proposition by Igor, we are
working on it.

 If this can be done in a non-intrusive way, then you
 can just do it yourself and provide it as a wicketstuff module.  If
 enough folks use it and say man, I really wish the core framework
 worked like this, then perhaps we consider putting it into the core.

Sounds completely fair to me.

**
Martin


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 Progress is made by people who have understanding, not by the ignorant.
 You're not in a position to make suggestions about extending Wicket if
 you don't yet understand how to use the powers it already has.

I feel I understand its powers and limitations. Its powers have not
shown to be a problem, but its limitations need some alleviation ;)

**
Martin


 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 9:23 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 So instead of asking, How can we make Wicket different so that my
 problem will go away? the proper question to try first is, What is
 the
 Wicket way of solving my problem?

 That's not how proggress is made...

 **
 Martin



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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 17:23:18 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

  So instead of asking, How can we make Wicket different so that my
  problem will go away? the proper question to try first is, What
  is the Wicket way of solving my problem?
 
 That's not how proggress is made...

So far you are *still* the only one in favor of this whole idea. You
have not really replied to any of proposed solutions except with
[paraphrased] I don't want to do it that way or some silliness about
child's play.

At the same time, you have not responded to valid criticisms like the
problems with enabledInHierarchy (at least I haven't seen any such
response).

I finally understand your problem now that it has been defined
somewhat, but I do not think your suggestion is a good solution to it.
There are other solutions with a much smaller impact.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Well.. that's what we are doing, at runtime.

**
Martin

2010/11/9 manuelbarzi manuelba...@gmail.com:
 may it be enough just create an independent simple
 html-code-processor-to-wicket-java-code-tool, that would auto-generate that
 tedious code you would like to avoid? a simple java-class-processor-tool may
 help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
 already exists...

 On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Can you see the matrix?

 ;)

 If you have:

 html
  form wicket:id=form
     input wicket:id=input .../
  /form
 /html

 public class MyPage extends WebPage {
    public MyPage () {
       add(new Form(form));
       add(new TextField(input, model)); // Wicket could
 automatically handle parse hierarchy from markup
    }
 }

 **
 Martin

 2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
  1. I want freedom inside panels.
 
  2. Doubly defined hierarhices are redundant. Server-side hierarchy can
  be automatically deduced from markup hierarcy. Such tasks should be
  done by COMPUTER. Not coder.
 
  **
  Martin
 
  2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
 
  I think if you find component hierarchies to be hell, you probably
 aren't
  using Wicket right. Break things down into small reusable chunks using
  Panels and you will find everything gets much, much easier.
  --
  View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

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




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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
I think we need to try to put our heads together on this one.  I don't
necessarily think this approach is the best, but I haven't really had
a chance to wrap my head around it yet, frankly.  Do we really think
this is that big of a problem that we need to change the whole
paradigm of the framework to address it?  Perhaps you can create a new
container component that does all of this stuff with some pre-render
magic or something?  If you want to use it, you can.  If not, you
don't have to.  So, if you're the type that likes this loosey goosey
stuff, you basically wrap your pages with one of these things to
enable this type of behavior.  I don't know.  This is just off the top
of my head.  Still not done with my morning coffee.

On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote:
 I think we have to make a vote whether this feature has to be investigated
 further.
 There are over 90 mails in the thread and I have the feeling that only
 Martin Makundi likes the idea.

 On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com
 wrote:

 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.

 Your constructor can call the component-creation methods to assemble the
 component hierarchy to match the HTML.

 Then, when you want a panel with a different hierarchy you subclass the
 panel, override the constructor to create the 2nd component hierarchy,
 and provide the new panel its own HTML page.

 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.

 /Frank

 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 Hi!

  Isn't this exactly the reason we've got CSS?

 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/

  HTML shouldn't really be used for lookfeel and the size and placement
 of
  components can perfectly be defined using CSS classes.

 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).

 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.

 **
 Martin

 
  Matt
 
  On 2010-11-09 13:34, Martin Makundi wrote:
 
  Also making skins for different devices / screen sizes becomes
 easier.
 
  **
  Martin
 
  2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:
 
  In simple cases it makes no difference. It makes real difference
 with
  some complex widgets (for example search components) that must be
  reused on many pages and they should render differently on each
 page
  depending on how much space and what context they are in. I don't
 like
  duplicating code even if it is gui code.
 
  Sounds like the first appealing argument slowly comming out of
  surrounding fuzz =)
 
 
 

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


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




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



Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread Ernesto Reinaldo Barreiro
Armando,

Thanks for sharing. Did you know about [1] and [2]?

Regards,

Ernesto

1-http://code.google.com/p/wiquery/source/browse/trunk/src/main/java/org/odlabs/wiquery/ui/draggable/DraggableAjaxBehavior.java
2-http://code.google.com/p/wiquery/source/browse/trunk/src/main/java/org/odlabs/wiquery/ui/droppable/DroppableAjaxBehavior.java


On Tue, Nov 9, 2010 at 2:30 PM, armandoxxx armando@dropchop.com wrote:

 Just to let everyone know, this is just a simple imeplementation, there are
 no events triggered on draggable and therefore no methods called, so if
 anyone needs it just implement it ..
 So all the NPE checks and that kinda  stuff is still needed !
 All I needed for my case was to get the dropped component and I needed it to
 be done with JQuery.

 Regards

 Armando



 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033703.html
 Sent from the Users forum mailing list archive at Nabble.com.

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



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



RE: Free wicket from component hierarchy hell

2010-11-09 Thread John Owen
Do we really think this is that big of a problem that we need to change the 
whole paradigm of the framework to address it?

IMO, No.

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On 
Behalf Of James Carman
Sent: Tuesday, November 09, 2010 9:06 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

I think we need to try to put our heads together on this one.  I don't
necessarily think this approach is the best, but I haven't really had
a chance to wrap my head around it yet, frankly.  Do we really think
this is that big of a problem that we need to change the whole
paradigm of the framework to address it?  Perhaps you can create a new
container component that does all of this stuff with some pre-render
magic or something?  If you want to use it, you can.  If not, you
don't have to.  So, if you're the type that likes this loosey goosey
stuff, you basically wrap your pages with one of these things to
enable this type of behavior.  I don't know.  This is just off the top
of my head.  Still not done with my morning coffee.

On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote:
 I think we have to make a vote whether this feature has to be investigated
 further.
 There are over 90 mails in the thread and I have the feeling that only
 Martin Makundi likes the idea.

 On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com
 wrote:

 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.

 Your constructor can call the component-creation methods to assemble the
 component hierarchy to match the HTML.

 Then, when you want a panel with a different hierarchy you subclass the
 panel, override the constructor to create the 2nd component hierarchy,
 and provide the new panel its own HTML page.

 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.

 /Frank

 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 Hi!

  Isn't this exactly the reason we've got CSS?

 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/

  HTML shouldn't really be used for lookfeel and the size and placement
 of
  components can perfectly be defined using CSS classes.

 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).

 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.

 **
 Martin

 
  Matt
 
  On 2010-11-09 13:34, Martin Makundi wrote:
 
  Also making skins for different devices / screen sizes becomes
 easier.
 
  **
  Martin
 
  2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:
 
  In simple cases it makes no difference. It makes real difference
 with
  some complex widgets (for example search components) that must be
  reused on many pages and they should render differently on each
 page
  depending on how much space and what context they are in. I don't
 like
  duplicating code even if it is gui code.
 
  Sounds like the first appealing argument slowly comming out of
  surrounding fuzz =)
 
 
 

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


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




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


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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 10:32 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 I've been dabbling with Wicket for 2,5 years now, and I have now
 finally come up with this request for the core wicketeers to show us
 the correct way to patch this particular issue.


I'm not necessarily saying it's not an issue.  I get what you're
saying about having to stick to the hierarchy when designing markup
files.  I just don't know whether this approach is the best or not.
Again, I really haven't had a chance to sit down and think it through.


 Sounds completely fair to me.


Why don't you put this work into wicketstuff (or flesh it out more
with Igor in his git repo first and then move it), so we can see what
it's all about and perhaps try it out for ourselves?

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



Re: wicket 1.4.12 first time page visit

2010-11-09 Thread Martin Grigorov
From which version did you upgrade ?
I guess 1.4.8 (extracted from your recent mails about wicketstuff-push).

You can start any Java profiler (JProfiler, YourKit, ...) and see what is
slow.

On Tue, Nov 9, 2010 at 4:08 PM, fachhoch fachh...@gmail.com wrote:


 we noticed first time visit to the page is slow compared to next visits, we
 are using wicket 1.4.12, is there anything I can do to improve performance.

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/wicket-1-4-12-first-time-page-visit-tp3034418p3034418.html
 Sent from the Users forum mailing list archive at Nabble.com.

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




Re: Wicket JQuery drag and drop behaviors

2010-11-09 Thread Martin Makundi
Nice.

**
Martin

2010/11/9 armandoxxx armando@dropchop.com:


 /**
         * Notification method that a drop happened on this component.
         * @param theComponent  reference to dropped component.
         */
        protected void onDrop(final AjaxRequestTarget theTarget, final 
 Component
 theComponent) {
                System.out.println(Dropped: + 
 theComponent.getClass().getName());
        }


 you get the draggable component that was dropped.

 Regards

 Armando


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3033686.html
 Sent from the Users forum mailing list archive at Nabble.com.

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



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



Re: Wicket ajax-enabled enclosures

2010-11-09 Thread Martin Makundi
Hi!

Has this been attempted before? Would it be a good idea to go at it?
Sure would help removing some boilerplate webmarkupcontainer code.
Existing jira issue for this?

**
Martin

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

 Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ?

 What I mean is that when I have:
 wicket:enclosure child=optional-field
 tr
   tdoptional content/td
    tdinput type=text wicket:id=optional-field//td
 /tr
 /wicket

 If I set it invisible via ajax I cannot set it visible again.

 Instead, is there a way to do something like:


 tr wicket:enclosure=child:optional-field
   tdoptional content/td
    tdinput type=text wicket:id=optional-field//td
 /tr

 So that it would automatically handle visible/hidden
 setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
 element via ajax?

 @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/


 **
 Martin


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



Re: Wicket ajax-enabled enclosures

2010-11-09 Thread Martin Grigorov
On Tue, Nov 9, 2010 at 4:39 PM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

 Hi!

 Has this been attempted before? Would it be a good idea to go at it?
 Sure would help removing some boilerplate webmarkupcontainer code.
 Existing jira issue for this?

At least I haven't seen one.


 **
 Martin

 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
  Hi!
 
  Does wicket:enclosure have capability to
 setOutputMarkupPlaceholderTag ?
 
  What I mean is that when I have:
  wicket:enclosure child=optional-field
  tr
tdoptional content/td
 tdinput type=text wicket:id=optional-field//td
  /tr
  /wicket
 
  If I set it invisible via ajax I cannot set it visible again.
 
  Instead, is there a way to do something like:
 
 
  tr wicket:enclosure=child:optional-field
tdoptional content/td
 tdinput type=text wicket:id=optional-field//td
  /tr
 
  So that it would automatically handle visible/hidden
  setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
  element via ajax?
 
  @See
 http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/
 
 
  **
  Martin
 

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




Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 At the same time, you have not responded to valid criticisms like the
 problems with enabledInHierarchy (at least I haven't seen any such
 response).

@Carl-Erik
Reason why I haven't commented your enabledInHierarchy comment is
because it would not afect it in any way.

I hope the proposition will be clear when we have it ready. We are
working on Igor's proposal.


 I'm not necessarily saying it's not an issue.  I get what you're
 saying about having to stick to the hierarchy when designing markup
 files.  I just don't know whether this approach is the best or not.
 Again, I really haven't had a chance to sit down and think it through.

@James
I think Igor thought it through very well.. also Sebastian, Rodolfo
and Michal have had very proactive comments.

I apologise that it takes some time to code it, but we'll be back with
a freebie for everybody to try out for themselves ;)

**
Martin

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



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



Re: Wicket ajax-enabled enclosures

2010-11-09 Thread Martin Makundi
It is pretty similar syntax to wicket:message. any pointers how to
implement it or if there would be some pitfalls? I understand
transarent markup containers are somewhat tricky?

**
Martin

2010/11/9 Martin Grigorov mgrigo...@apache.org:
 On Tue, Nov 9, 2010 at 4:39 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

 Hi!

 Has this been attempted before? Would it be a good idea to go at it?
 Sure would help removing some boilerplate webmarkupcontainer code.
 Existing jira issue for this?

 At least I haven't seen one.


 **
 Martin

 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
  Hi!
 
  Does wicket:enclosure have capability to
 setOutputMarkupPlaceholderTag ?
 
  What I mean is that when I have:
  wicket:enclosure child=optional-field
  tr
    tdoptional content/td
     tdinput type=text wicket:id=optional-field//td
  /tr
  /wicket
 
  If I set it invisible via ajax I cannot set it visible again.
 
  Instead, is there a way to do something like:
 
 
  tr wicket:enclosure=child:optional-field
    tdoptional content/td
     tdinput type=text wicket:id=optional-field//td
  /tr
 
  So that it would automatically handle visible/hidden
  setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
  element via ajax?
 
  @See
 http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/
 
 
  **
  Martin
 

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




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



RE: Free wicket from component hierarchy hell

2010-11-09 Thread Frank Silbermann
If the component hierarchy can be changed without changing behavior or
semantics, then why are the components in a hierarchy to begin with?
Why aren't all the components being moved around already siblings at the
same level?  Does Wicket require that the order of sibling Wicket
components match the order at which simply HTML elements appear?

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com]
On Behalf Of James Carman
Sent: Tuesday, November 09, 2010 9:39 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

I get what you're
saying about having to stick to the hierarchy when designing markup
files.  I just don't know whether this approach is the best or not.
Again, I really haven't had a chance to sit down and think it through.


 Sounds completely fair to me.


Why don't you put this work into wicketstuff (or flesh it out more
with Igor in his git repo first and then move it), so we can see what
it's all about and perhaps try it out for ourselves?

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


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



Re: Wicket ajax-enabled enclosures

2010-11-09 Thread Brian Topping
It's the same pattern as the last suggestion you had: 

1) Generate a patch with a Quickstart that demonstrates the proposed 
functionality
2) Attach it to a Jira issue

First impressions matter a lot, so if you post the Jira without the code, it's 
going to get ignored, possibly even after you post the code, which would waste 
your time.

Why not get yourself organized and present yourself professionally?  You sound 
eager and capable, show people your best!

Brian

On Nov 9, 2010, at 10:39 AM, Martin Makundi wrote:

 Hi!
 
 Has this been attempted before? Would it be a good idea to go at it?
 Sure would help removing some boilerplate webmarkupcontainer code.
 Existing jira issue for this?
 
 **
 Martin
 
 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hi!
 
 Does wicket:enclosure have capability to setOutputMarkupPlaceholderTag ?
 
 What I mean is that when I have:
 wicket:enclosure child=optional-field
 tr
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
 /tr
 /wicket
 
 If I set it invisible via ajax I cannot set it visible again.
 
 Instead, is there a way to do something like:
 
 
 tr wicket:enclosure=child:optional-field
   tdoptional content/td
tdinput type=text wicket:id=optional-field//td
 /tr
 
 So that it would automatically handle visible/hidden
 setOutputMarkupPlaceholderTag flavour so that I can repaint a hidden
 element via ajax?
 
 @See http://jawher.wordpress.com/2009/09/17/wicket-enclosures-and-ajax-no-no/
 
 
 **
 Martin
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
 If the component hierarchy can be changed without changing behavior or
 semantics, then why are the components in a hierarchy to begin with?
 Why aren't all the components being moved around already siblings at the
 same level?  Does Wicket require that the order of sibling Wicket
 components match the order at which simply HTML elements appear?


You could do that, but I think Martin is trying to take it a step
further allowing you to have an arbitrary hierarchy in your markup and
just figure it out at runtime.  Wicket doesn't care what order you add
stuff to the page/component as long as they're all on the same level
within the hierarchy.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 You could do that, but I think Martin is trying to take it a step
 further allowing you to have an arbitrary hierarchy in your markup and
 just figure it out at runtime.  Wicket doesn't care what order you add
 stuff to the page/component as long as they're all on the same level
 within the hierarchy.

Yes, and if  they are at different levels in the hierarchy, Wicket can
figure that out also, at runtime.

**
Martin


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 10:58 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 Yes, and if  they are at different levels in the hierarchy, Wicket can
 figure that out also, at runtime.


What happens if a sub-component changes one of the ids of one of its
components that it contains?  Is that then going to break your page
because it's going to grab that id from you?

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



Cannot get current page from AjaxPagingNavigator

2010-11-09 Thread Vishal Popat
Hi all,

For some reason I cannot get the current page number. This is the relevant
part of my code:

 

PageableListView dataList = new PageableListView(dataList, results, 10) {

protected void populateItem(ListItem item) {

..

}

}

 

AjaxPagingNavigator pagination = new
AjaxPagingNavigator(navigator, dataList);

add(pagination);

 

Label currentPage = new Label(currentPage,
pagination.getPageable().getCurrentPage() + );

currentPage.setOutputMarkupId(true);

add(currentPage);

 

currentPage always returns 0.

I have also tried PagingNavigator with similar results.

 

Can anyone tell me what I have missed?

 

Regards

 

Vishal



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

 What happens if a sub-component changes one of the ids of one of its
 components that it contains?  Is that then going to break your page
 because it's going to grab that id from you?

Igor explained that # Components can be queued to any container, and
can only be added to the hierarchy that stems from that container,
thereby solving the security requirement

https://github.com/ivaynberg/wicket/tree/component-queuing

**
Martin


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 17:46:13 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 @Carl-Erik
 Reason why I haven't commented your enabledInHierarchy comment is
 because it would not afect it in any way.
 
 I hope the proposition will be clear when we have it ready. We are
 working on Igor's proposal.

It will be interesting to see how you propose not affecting something
that depends on the hierarchy when you remove the hierarchy.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 10:51:49 -0500
James Carman ja...@carmanconsulting.com wrote:

 On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
 frank.silberm...@fedex.com wrote:
  If the component hierarchy can be changed without changing behavior
  or semantics, then why are the components in a hierarchy to begin
  with? Why aren't all the components being moved around already
  siblings at the same level?  Does Wicket require that the order of
  sibling Wicket components match the order at which simply HTML
  elements appear?
 
 
 You could do that, but I think Martin is trying to take it a step
 further allowing you to have an arbitrary hierarchy in your markup and
 just figure it out at runtime.  Wicket doesn't care what order you add
 stuff to the page/component as long as they're all on the same level
 within the hierarchy.

I think you misunderstood Frank's point. Why are the components in a
hierarchy in the first place, if the hierarchy can be changed without
changing behavior or semantics? They can simply be flat in the parent
then.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 one of the nice things of wicket is that java-code (programmer) and
 html-code (designer) are quite independent. only watching a wicket-java-file
 does a programmer deduce the structure and behaviour of the corresponding
 view, both things, without fully depending on inspecting html for
 understanding it all, in most cases.

 so, would your proposal tie programmers to requiring to watch the html-code
 to understand structure instead of a self-contained java-code. that's what
 old-fashioned frameworks do...

Quite the opposite in the general case. I cannot come up with an
example case that would require to watch the html code, more than we
must do already now.

**
Martin


 On Tue, Nov 9, 2010 at 5:08 PM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  @Carl-Erik
  Reason why I haven't commented your enabledInHierarchy comment is
  because it would not afect it in any way.
 
  I hope the proposition will be clear when we have it ready. We are
  working on Igor's proposal.
 
  It will be interesting to see how you propose not affecting something
  that depends on the hierarchy when you remove the hierarchy.

 Sorry for miscommunicating.. we are not removing hierarcy. We are
 trying to automatically nest the components according to the hierarchy
 defined in markup.

 **
 Martin

 
  Carl-Eric
  www.wicketbuch.de
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

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




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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 18:04:44 +0200
Martin Makundi martin.maku...@koodaripalvelut.com wrote:

 Igor explained that # Components can be queued to any container, and
 can only be added to the hierarchy that stems from that container,
 thereby solving the security requirement
 
 https://github.com/ivaynberg/wicket/tree/component-queuing

Having read the readme there, this is starting to finally make some
sense. This proposed solution might actually work without too much
breakage.

I still don't see the necessity for this change, but I'm willing to
change my -1 to a -0.5.

I'll go for a -0 if it can be shown that the impact of this on the rest
of Wicket is minimal (i.e., it needs few code changes and doesn't break
any assumptions in framework or user code, for example about when
exactly the component tree is available).

Carl-Eric
www.wicketbuch.de

PS: I think much of this controversy could have been streamlined by
pointing to a concept-complete implementation or at least making a
properly thought-out suggestion, instead of all the name-calling that
went on. (Almost) No offense taken, just a suggestion for the future.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 Say you have two forms on one panel (don't know if this is the best
 example or not, but here goes).  You want to move a field from one
 panel to another.  You'd have to do that in code with the traditional
 approach.  With the queued approach, you'd just queue all your
 components to the parent container and it would auto-add them to the
 correct subcomponent as it finds them in the markup.

 With this, the order does matter, though.  Suppose you had two
 components you wanted to queue with the same id, completely different
 components.  If you reverse their order, then they're auto-added in a
 different order.

Yeah ids must be unique per each level and ofcourse if you have markup like:

div wicket:id=adiv wicket:id=a/div/div

If you have code like:
panel {
  queue(a(a));
  a.queue(a(a));
}

It is pretty evident what goes into where but not very good naming convention ;)

**
Martin


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



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



Updating model object on AjaxFallbackDefaultDataTable page change

2010-11-09 Thread Matt Schmidt
I have a CheckGroup that contains an AjaxFallbackDefaultDataTable that has a
column containing a Check. As long as I click my submit button while on the
first page of the DataTable, the model object of the CheckGroup is updated
as expected with the items I had checked. However, if I check some
checkboxes and then go to page 2 of the DataTable, the CheckGroup's model
object is not updated and I lose everything I checked on page 1.

The DataTable class has an onPageChanged() event, but it appears that it
is called after the page is actually changed.

My other thought was to add an AjaxFormComponentUpdatingBehavior to the
Check, but Check is not a FormComponent.

Any thoughts?

Thanks,
Matt


Re: Configuration of AbstractCalendar

2010-11-09 Thread Igor Vaynberg
the value should be available in the formcomponent's model the
datepicker is attached to.

-igor


On Tue, Nov 9, 2010 at 2:27 AM, Jan Ferko julyl...@gmail.com wrote:
 Thanks,

 I figured it out. I have one more question ... can i use wicket behaviour to
 retrieve selected date from calendar or i have to write some JS hacks to do
 it?


 On 11/06/2010 06:38 PM, Igor Vaynberg wrote:

 i think its whatever format the yui component expects.

 -igor

 On Fri, Nov 5, 2010 at 9:25 AM, Jan Ferkojulyl...@gmail.com  wrote:


 Hi,

 Can anyone tell me what is format of map for
 AbstractCalendar.configureWidgetProperties(Map map) ? For example I want
 to
 set navigator property to true, but map.put(navigator, true) doesn't
 work.

 thanks for answer
 Jan



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




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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 Igor explained that # Components can be queued to any container, and
 can only be added to the hierarchy that stems from that container,
 thereby solving the security requirement

 https://github.com/ivaynberg/wicket/tree/component-queuing


Sorry, I was thinking for some reason that the depth-first search
through the current component's hierarchy would actually traverse into
subcomponent's markup, but I don't think it will.  It will stay within
the current component's markup looking for the matching id.  Could
fragments screw this up, since their markup is actually contained
within the markup of their parent container?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 What happens if a sub-component changes one of the ids of one of its
 components that it contains?  Is that then going to break your page
 because it's going to grab that id from you?

Also depends what you mean by a component. A panel sitting on a
panel has its own markup so it won't grab anything.

**
Martin

 Igor explained that # Components can be queued to any container, and
 can only be added to the hierarchy that stems from that container,
 thereby solving the security requirement

 https://github.com/ivaynberg/wicket/tree/component-queuing

 **
 Martin


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




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



Re: Cannot get current page from AjaxPagingNavigator

2010-11-09 Thread jcgarciam

You are using an static model, which only knows about the value by the time
of construction. Use a dynamic model

i.e: (make sure you define pagination as final)

 Label currentPage = new Label(currentPage, new LoadableDetachableModel(){
 public Object load(){

 return pagination.getPageable().getCurrentPage();
}

});


On Tue, Nov 9, 2010 at 1:04 PM, vp143 [via Apache Wicket] 
ml-node+3034524-366758351-65...@n4.nabble.comml-node%2b3034524-366758351-65...@n4.nabble.com
 wrote:

 Hi all,

 For some reason I cannot get the current page number. This is the relevant
 part of my code:



 PageableListView dataList = new PageableListView(dataList, results, 10) {


 protected void populateItem(ListItem item) {

 ..

 }

 }



 AjaxPagingNavigator pagination = new
 AjaxPagingNavigator(navigator, dataList);

 add(pagination);



 Label currentPage = new Label(currentPage,
 pagination.getPageable().getCurrentPage() + );

 currentPage.setOutputMarkupId(true);

 add(currentPage);



 currentPage always returns 0.

 I have also tried PagingNavigator with similar results.



 Can anyone tell me what I have missed?



 Regards



 Vishal



 --
  View message @
 http://apache-wicket.1842946.n4.nabble.com/Cannot-get-current-page-from-AjaxPagingNavigator-tp3034524p3034524.html
 To start a new topic under Apache Wicket, email
 ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com
 To unsubscribe from Apache Wicket, click 
 herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=.





-- 
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Cannot-get-current-page-from-AjaxPagingNavigator-tp3034524p3034563.html
Sent from the Users forum mailing list archive at Nabble.com.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 When fragments are added they materialize as natural markup at the
 junction point?


I don't know the answer to that.  I'm asking, myself. :)  Just trying
to make sure the queue approach doesn't break with these typical use
cases.  I use fragments a lot! :)

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:

 I think you misunderstood Frank's point. Why are the components in a
 hierarchy in the first place, if the hierarchy can be changed without
 changing behavior or semantics? They can simply be flat in the parent
 then.


Say you have two forms on one panel (don't know if this is the best
example or not, but here goes).  You want to move a field from one
panel to another.  You'd have to do that in code with the traditional
approach.  With the queued approach, you'd just queue all your
components to the parent container and it would auto-add them to the
correct subcomponent as it finds them in the markup.

With this, the order does matter, though.  Suppose you had two
components you wanted to queue with the same id, completely different
components.  If you reverse their order, then they're auto-added in a
different order.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 https://github.com/ivaynberg/wicket/tree/component-queuing

 Sorry, I was thinking for some reason that the depth-first search
 through the current component's hierarchy would actually traverse into
 subcomponent's markup, but I don't think it will.  It will stay within
 the current component's markup looking for the matching id.  Could
 fragments screw this up, since their markup is actually contained
 within the markup of their parent container?

When fragments are added they materialize as natural markup at the
junction point?

**
Martin

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread manuelbarzi
Martin, isn't it all a matter of principles towards keeping a correct
separation of concerns?

one of the nice things of wicket is that java-code (programmer) and
html-code (designer) are quite independent. only watching a wicket-java-file
does a programmer deduce the structure and behaviour of the corresponding
view, both things, without fully depending on inspecting html for
understanding it all, in most cases.

so, would your proposal tie programmers to requiring to watch the html-code
to understand structure instead of a self-contained java-code. that's what
old-fashioned frameworks do...

On Tue, Nov 9, 2010 at 5:08 PM, Martin Makundi 
martin.maku...@koodaripalvelut.com wrote:

  @Carl-Erik
  Reason why I haven't commented your enabledInHierarchy comment is
  because it would not afect it in any way.
 
  I hope the proposition will be clear when we have it ready. We are
  working on Igor's proposal.
 
  It will be interesting to see how you propose not affecting something
  that depends on the hierarchy when you remove the hierarchy.

 Sorry for miscommunicating.. we are not removing hierarcy. We are
 trying to automatically nest the components according to the hierarchy
 defined in markup.

 **
 Martin

 
  Carl-Eric
  www.wicketbuch.de
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

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




Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 @Carl-Erik
 Reason why I haven't commented your enabledInHierarchy comment is
 because it would not afect it in any way.

 I hope the proposition will be clear when we have it ready. We are
 working on Igor's proposal.

 It will be interesting to see how you propose not affecting something
 that depends on the hierarchy when you remove the hierarchy.

Sorry for miscommunicating.. we are not removing hierarcy. We are
trying to automatically nest the components according to the hierarchy
defined in markup.

**
Martin


 Carl-Eric
 www.wicketbuch.de

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Sebastian
From my understanding the proposal works like this that you have a 
partially code controlled hierarchy of components when you need it for 
functional reasons (security, AJAX refresh, visibility, etc). You can 
define the parent of a component but technical you allow child 
components being nested at will in the HTML markup (below that code 
controlled parent). So if you do parent.add(component) you say that the 
component must be either added as a direct or indirect child to this 
parent = if you do parent.setVisible(false) all childs will still be 
invisible no matter how they are nested among themselves.


So you give the HTML designer a bit more freedom in layouting components 
below a given code controlled parent. I think that would be a reasonable 
approach.



 On 09.11.2010 17:05, Carl-Eric Menzel wrote:

On Tue, 9 Nov 2010 17:46:13 +0200
Martin Makundimartin.maku...@koodaripalvelut.com  wrote:


@Carl-Erik
Reason why I haven't commented your enabledInHierarchy comment is
because it would not afect it in any way.

I hope the proposition will be clear when we have it ready. We are
working on Igor's proposal.


It will be interesting to see how you propose not affecting something
that depends on the hierarchy when you remove the hierarchy.

Carl-Eric
www.wicketbuch.de

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






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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 Yeah ids must be unique per each level and ofcourse if you have markup like:

 div wicket:id=adiv wicket:id=a/div/div

 If you have code like:
 panel {
  queue(a(a));
  a.queue(a(a));
 }


This could be a problem.  Say you do have two forms on the same page.
One form edits a Person and the other edits a Department.  Each of
which have a name field (with id name) which are queued/auto-added
so that the Department's name field is queued before the Person's name
field.  To begin with, in the markup, the Department form comes before
the Person form.  Now, what if the designer switches the order of
the markup and puts the Person form before the Department form?  Then,
the wrong name field will be added to the wrong form.  Am I
understanding this correctly?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Carl-Eric Menzel
On Tue, 9 Nov 2010 11:33:31 -0500
James Carman ja...@carmanconsulting.com wrote:

 Say you have two forms on one panel (don't know if this is the best
 example or not, but here goes).  You want to move a field from one
 panel to another.  You'd have to do that in code with the traditional
 approach.  With the queued approach, you'd just queue all your
 components to the parent container and it would auto-add them to the
 correct subcomponent as it finds them in the markup.

Are you moving a field from one form to another? But that does change
the semantics, doesn't it? If it doesn't, why are there two forms?

 With this, the order does matter, though.  Suppose you had two
 components you wanted to queue with the same id, completely different
 components.  If you reverse their order, then they're auto-added in a
 different order.

Ouch. I think this has the potential to be a showstopper. This will be
an endless source of hard-to-find bugs. I think there needs to be a
unique-id requirement when you start using queue.

Right now we require unique-ids on the same hierarchy level, i.e.
direct descendants of the same component. With queue, we're basically
extending necessity that to the whole subtree.

Carl-Eric
www.wicketbuch.de

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
so queue each formcomponet under the form they belong to. that way
they cannot be moved outside the form.

-igor

On Tue, Nov 9, 2010 at 8:46 AM, James Carman ja...@carmanconsulting.com wrote:
 On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:

 Yeah ids must be unique per each level and ofcourse if you have markup like:

 div wicket:id=adiv wicket:id=a/div/div

 If you have code like:
 panel {
  queue(a(a));
  a.queue(a(a));
 }


 This could be a problem.  Say you do have two forms on the same page.
 One form edits a Person and the other edits a Department.  Each of
 which have a name field (with id name) which are queued/auto-added
 so that the Department's name field is queued before the Person's name
 field.  To begin with, in the markup, the Department form comes before
 the Person form.  Now, what if the designer switches the order of
 the markup and puts the Person form before the Department form?  Then,
 the wrong name field will be added to the wrong form.  Am I
 understanding this correctly?

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 PS: I think much of this controversy could have been streamlined by
 pointing to a concept-complete implementation or at least making a
 properly thought-out suggestion, instead of all the name-calling that
 went on. (Almost) No offense taken, just a suggestion for the future.

My apologies. I am quite bad at communicating my wicked ideas.
However, the well thought suggestions from the wicketeers were
necessary to get the solution growing. The solution and also the
concept was invented collaboratively during the thread. For that I am
very thankful ;)

**
Martin


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



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



Re: Cannot get current page from AjaxPagingNavigator

2010-11-09 Thread Pedro Santos
Use an dinamic model, ex:

Label currentPage = new Label(currentPage, new
AbstractReadOnlyModelString() {
public String getObject() {
return pagination.getPageable().getCurrentPage();
}
});

On Tue, Nov 9, 2010 at 2:04 PM, Vishal Popat vishal.po...@cipriati.co.ukwrote:

 Hi all,

 For some reason I cannot get the current page number. This is the relevant
 part of my code:



 PageableListView dataList = new PageableListView(dataList, results, 10) {

protected void populateItem(ListItem item) {

..

 }

}



AjaxPagingNavigator pagination = new
 AjaxPagingNavigator(navigator, dataList);

add(pagination);



Label currentPage = new Label(currentPage,
 pagination.getPageable().getCurrentPage() + );

currentPage.setOutputMarkupId(true);

add(currentPage);



 currentPage always returns 0.

 I have also tried PagingNavigator with similar results.



 Can anyone tell me what I have missed?



 Regards



 Vishal




-- 
Pedro Henrique Oliveira dos Santos


Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:

 Are you moving a field from one form to another? But that does change
 the semantics, doesn't it? If it doesn't, why are there two forms?


Both forms edit one particular object (say a Person).  They just
edit different values on the same object.  Again, I'm not sure this is
the best example, but it's at least plausible.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
On Tue, Nov 9, 2010 at 7:36 AM, John Owen jo...@globalscape.com wrote:
 Do we really think this is that big of a problem that we need to change the 
 whole paradigm of the framework to address it?

it will not be changing the paradigm. it is adding a new method for
you to add components. use it if you want, dont use it if you dont.

-igor


 IMO, No.

 -Original Message-
 From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On 
 Behalf Of James Carman
 Sent: Tuesday, November 09, 2010 9:06 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 I think we need to try to put our heads together on this one.  I don't
 necessarily think this approach is the best, but I haven't really had
 a chance to wrap my head around it yet, frankly.  Do we really think
 this is that big of a problem that we need to change the whole
 paradigm of the framework to address it?  Perhaps you can create a new
 container component that does all of this stuff with some pre-render
 magic or something?  If you want to use it, you can.  If not, you
 don't have to.  So, if you're the type that likes this loosey goosey
 stuff, you basically wrap your pages with one of these things to
 enable this type of behavior.  I don't know.  This is just off the top
 of my head.  Still not done with my morning coffee.

 On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov mgrigo...@apache.org wrote:
 I think we have to make a vote whether this feature has to be investigated
 further.
 There are over 90 mails in the thread and I have the feeling that only
 Martin Makundi likes the idea.

 On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann frank.silberm...@fedex.com
 wrote:

 Well then, why don't you have your base panel provide methods that
 generate the individual components, with methods that implement
 composite behaviors involving groups of components.

 Your constructor can call the component-creation methods to assemble the
 component hierarchy to match the HTML.

 Then, when you want a panel with a different hierarchy you subclass the
 panel, override the constructor to create the 2nd component hierarchy,
 and provide the new panel its own HTML page.

 If you don't like overriding the constructor along with the HTML, then
 you can build some sort of configurable constructor-constructor.

 /Frank

 -Original Message-
 From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
 Sent: Tuesday, November 09, 2010 6:55 AM
 To: users@wicket.apache.org
 Subject: Re: Free wicket from component hierarchy hell

 Hi!

  Isn't this exactly the reason we've got CSS?

 It's just the buzz, not the reality. Unfortunately often CSS doesn't
 quite cut it:
 * http://blog.iconara.net/2007/09/21/the-failure-of-css/

  HTML shouldn't really be used for lookfeel and the size and placement
 of
  components can perfectly be defined using CSS classes.

 In CSS the actual nesting of components plays a big role (div inside
 float inside abs top 0px ul relative etc.).

 If you want a professional finish, you will often need to pull
 components around the layers for different display. Even trying to
 pull one component will break wicket in strict hierarchy mode.

 **
 Martin

 
  Matt
 
  On 2010-11-09 13:34, Martin Makundi wrote:
 
  Also making skins for different devices / screen sizes becomes
 easier.
 
  **
  Martin
 
  2010/11/9 Vitaly Tsaplinvitaly.tsap...@gmail.com:
 
  In simple cases it makes no difference. It makes real difference
 with
  some complex widgets (for example search components) that must be
  reused on many pages and they should render differently on each
 page
  depending on how much space and what context they are in. I don't
 like
  duplicating code even if it is gui code.
 
  Sounds like the first appealing argument slowly comming out of
  surrounding fuzz =)
 
 
 

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


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




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


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



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



RE: Free wicket from component hierarchy hell

2010-11-09 Thread Frank Silbermann
I don't understand your example.  You have two forms on one panel.  You
wish to move a field (of one of the forms?) to another panel.  Doesn't
that imply that you've taken the field out of the form?

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com]
On Behalf Of James Carman
Sent: Tuesday, November 09, 2010 10:34 AM
To: users@wicket.apache.org
Subject: Re: Free wicket from component hierarchy hell

On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel
cmen...@wicketbuch.de wrote:

 I think you misunderstood Frank's point. Why are the components in a
 hierarchy in the first place, if the hierarchy can be changed without
 changing behavior or semantics? They can simply be flat in the parent
 then.


Say you have two forms on one panel (don't know if this is the best
example or not, but here goes).  You want to move a field from one
panel to another.  You'd have to do that in code with the traditional
approach.  With the queued approach, you'd just queue all your
components to the parent container and it would auto-add them to the
correct subcomponent as it finds them in the markup.

With this, the order does matter, though.  Suppose you had two
components you wanted to queue with the same id, completely different
components.  If you reverse their order, then they're auto-added in a
different order.



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 so queue each formcomponet under the form they belong to. that way
 they cannot be moved outside the form.


That's what happens in code not markup.  You could potentially
change what gets edited by the form merely by moving fields around in
the markup.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
 On Tue, 9 Nov 2010 10:51:49 -0500
 James Carman ja...@carmanconsulting.com wrote:

 On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
 frank.silberm...@fedex.com wrote:
  If the component hierarchy can be changed without changing behavior
  or semantics, then why are the components in a hierarchy to begin
  with? Why aren't all the components being moved around already
  siblings at the same level?  Does Wicket require that the order of
  sibling Wicket components match the order at which simply HTML
  elements appear?
 

 You could do that, but I think Martin is trying to take it a step
 further allowing you to have an arbitrary hierarchy in your markup and
 just figure it out at runtime.  Wicket doesn't care what order you add
 stuff to the page/component as long as they're all on the same level
 within the hierarchy.

 I think you misunderstood Frank's point. Why are the components in a
 hierarchy in the first place, if the hierarchy can be changed without
 changing behavior or semantics? They can simply be flat in the parent
 then.

sadly there are valid usecases for having the hierarchy purely for
design purposes. an easy example is:

tr wicket:id=repeatertdspan wicket:id=first/ span
wicket:id=last//td/tr

now the designer wants tds to have a css class based on some
condition. you now have to add a webmarkupcontainer to represent the
td and renest first and last labels into it. the container is there
purely for the design aspect.

with queuing you can queue first and last under the repeater item.
when you need to add css to td you simply queue the webmarkupcontainer
under the repeater item as well and wicket will properly nest the
labels in it for you.

another usecase is introducing an arbitrary webmarkupcontainer just to
have a div to repaint via ajax. it is hard to do this when refactoring
a complex page because you have to find all the components that now
need to be re-nested into the new container.

hopefully queuing can eliminate some of this noise and make it easier.

-igor


 Carl-Eric
 www.wicketbuch.de

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 That's what happens in code not markup.  You could potentially
 change what gets edited by the form merely by moving fields around in
 the markup.

With compoundpropertymodels yes if you don't restrict components
inside a form this can happen. For good or for bad.

For security reasons in general, you might want to use:

formA.queue(formAstuff);
formB.queue(formBstuff);

**
Martin


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
um. no. queued components cannot be moved out of their parent. so if
you queued field1 under form1 and the designer moves the tag tied to
field1 outside the tag tied to form1 you will get the same error you
would get now.

-igor

On Tue, Nov 9, 2010 at 8:50 AM, James Carman ja...@carmanconsulting.com wrote:
 On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 so queue each formcomponet under the form they belong to. that way
 they cannot be moved outside the form.


 That's what happens in code not markup.  You could potentially
 change what gets edited by the form merely by moving fields around in
 the markup.

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
 For security reasons in general, you might want to use:

 formA.queue(formAstuff);
 formB.queue(formBstuff);


But then you're right back where you started.  Why not just add and
not queue?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 um. no. queued components cannot be moved out of their parent. so if
 you queued field1 under form1 and the designer moves the tag tied to
 field1 outside the tag tied to form1 you will get the same error you
 would get now.


I'm not saying that.  I'm saying that if you queue the fields into the
parent of form1 and form2, then you are free to move them between the
forms solely in the markup.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann
frank.silberm...@fedex.com wrote:
 I don't understand your example.  You have two forms on one panel.  You
 wish to move a field (of one of the forms?) to another panel.  Doesn't
 that imply that you've taken the field out of the form?


Not to another panel.  To the other form within the same panel.  All
fields are queued to the panel, not the forms.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
ive outlined a couple of usecases when this is useful in another
email. see there.

-igor

On Tue, Nov 9, 2010 at 8:56 AM, James Carman ja...@carmanconsulting.com wrote:
 On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 For security reasons in general, you might want to use:

 formA.queue(formAstuff);
 formB.queue(formBstuff);


 But then you're right back where you started.  Why not just add and
 not queue?

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Igor Vaynberg
yes, and that would of course be a mistake. if you just queue
everything into the page you can cause serious security problems.

sometimes you have a hard container you want your components to live
under, and other times you dont care. you should always queue into the
hard container, just like you add to something under it now.

-igor

On Tue, Nov 9, 2010 at 8:57 AM, James Carman ja...@carmanconsulting.com wrote:
 On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 um. no. queued components cannot be moved out of their parent. so if
 you queued field1 under form1 and the designer moves the tag tied to
 field1 outside the tag tied to form1 you will get the same error you
 would get now.


 I'm not saying that.  I'm saying that if you queue the fields into the
 parent of form1 and form2, then you are free to move them between the
 forms solely in the markup.

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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:
 For security reasons in general, you might want to use:

 formA.queue(formAstuff);
 formB.queue(formBstuff);


 But then you're right back where you started.  Why not just add and
 not queue?

http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 yes, and that would of course be a mistake. if you just queue
 everything into the page you can cause serious security problems.

 sometimes you have a hard container you want your components to live
 under, and other times you dont care. you should always queue into the
 hard container, just like you add to something under it now.


The point is that this new approach can allow the designer to move
things around, potentially changing the semantics of how things work.
For example, a TextField may have validators set up on it that are
applicable within the context of one type of form, but may be
completely inappropriate in another form.  I'm not saying I'm against
the queue approach necessarily, but I want to point out how you can
get some pretty weird stuff happening just by moving the markup
around.  Do we want to open up that can of worms?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 The point is that this new approach can allow the designer to move
 things around, potentially changing the semantics of how things work.
 For example, a TextField may have validators set up on it that are
 applicable within the context of one type of form, but may be
 completely inappropriate in another form.  I'm not saying I'm against
 the queue approach necessarily, but I want to point out how you can
 get some pretty weird stuff happening just by moving the markup
 around.  Do we want to open up that can of worms?

(You) as a coder will be responsible for opening that can ;] For good
and for bad. Not wicket. Nor members of this discussion.

**
Martin


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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640


Did you mean to try to make me print this post?

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
 martin.maku...@koodaripalvelut.com wrote:

 http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640

 Did you mean to try to make me print this post?

Hehe... I did not find antoher way to point to a single post ;]

**
Martin



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



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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread James Carman
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:

 (You) as a coder will be responsible for opening that can ;] For good
 and for bad. Not wicket. Nor members of this discussion.


How many times have you done this:

add(new TextField(...))

when you meant to do:

someSubComponent.add(new TextField(..))

With add, you'll get an exception if the ids/hierarchy don't match up.
 Now, what if you're queueing instead?  Suppose the user does:

queue(new TextField(...))

which will work perfectly fine, but they meant to do (to enforce security):

someSubComponent.queue(new TextField(...))

Now, since security is not enforced the designer has the freedom to
move stuff around and royally hose things up.

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



Re: Free wicket from component hierarchy hell

2010-11-09 Thread Martin Makundi
Hi!

First of all, normally I have junit tests that validate the
functionality for me for regression purposes.

  Suppose the user does:

 queue(new TextField(...))

 which will work perfectly fine, but they meant to do (to enforce security):

 someSubComponent.queue(new TextField(...))

 Now, since security is not enforced the designer has the freedom to
 move stuff around and royally hose things up.

Yes, if you are unsure, you should use add() to make sure. You get
that extra security with that extra effort, if you want.

**
Martin



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



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



  1   2   >