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.
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
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
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
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
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
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,
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
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,
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
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
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
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?
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
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
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
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
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.
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
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
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
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
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
/**
* 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: +
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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?
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) {
..
}
}
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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,
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
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?
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
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
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
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
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
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,
On Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes, if you are unsure, you should use add() to make sure. You get
that extra security with that extra effort, if you want.
Again, the point is (regardless of unit tests) that you can
unknowingly do
1 - 100 of 147 matches
Mail list logo
