Just a thought for all you posters that provided wicket + jquery project
links. These links should also be available on wicket pages .. I googled for
wicket + jquery implementations before I started to implement my own tiny
little DnD behaviors, but found only wicket + "other JS libs" pages, so
th
Hey ...
No I haven't.
Regards
Armando
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-JQuery-drag-and-drop-behaviors-tp3033676p3035602.html
Sent from the Users forum mailing list archive at Nabble.com.
--
Did you take a look at jWicket
(http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jdk-1.5-parent/jwicket-parent/jwicket-ui/jwicket-ui-dragdrop)?
-Ursprüngliche Nachricht-
Von: armandoxxx [mailto:armando@dropchop.com]
Gesendet: Dienstag, 9. November 2
This isn't a big limitation, all you have to do is store the state in an object
separate from the component hierarchy. Then have the components access that
shared state. Keep MVC principles in mind: The model is your state, the
component is the controller.
On Nov 9, 2010, at 10:41 PM, Dmitr
Hello all,
I'm new to Wicket. Just wonder about subj (theoretical interest). On one
hand, stateful component model has no architectural limitations on its
own preventing me from reattaching component to different parent, just
like I can do with desktop applications or with any self-contained tree
Hello, I have a simple form with some RequiredTextFields.
When the user leaves some of them blank, the corresponding messages
show up in the feedback panel telling them they are required.
The issue I am having is that once this happens, the onSubmit() method
is no longer called and wicket starts c
Are you suggesting to override
AjaxPagingNavigator.newPagingNavigationIncrementLink() and
AjaxPagingNavigator.newPagingNavigationLink() and implement our own
navigation links similar to AjaxPagingNavigationIncrementLink and
AjaxPagingNavigationLink that do the same thing except extends
SubmitLink r
On Tue, Nov 9, 2010 at 4:07 PM, Henrique wrote:
> Hello, I'll try to make this simple.
> User fills in some data, clicks submit to persist it but since he has
> to login first, he is redirected to a login page (via throw new
> RestartResponseAtInterceptPageException(Login.class); ).
> He logs in a
Hello, I'll try to make this simple.
User fills in some data, clicks submit to persist it but since he has
to login first, he is redirected to a login page (via throw new
RestartResponseAtInterceptPageException(Login.class); ).
He logs in and is redirected back to the original page (via
continueToO
nah. you go ahead. the AutoComponentSource sounds vary vague, you will
need to elaborate it.
-igor
On Tue, Nov 9, 2010 at 12:58 PM, James Carman
wrote:
> on dev list? You wanna start it?
>
> On Tue, Nov 9, 2010 at 3:57 PM, Igor Vaynberg wrote:
>> can we fork this into another thread?
>>
>> -ig
see my last suggestion and replace navigator's links with submitlinks
-igor
On Tue, Nov 9, 2010 at 1:02 PM, Matt Schmidt wrote:
> Yes that works for the first page - only on that page are the javascript
> behaviors rendered.
>
> Basically, we are looking for a way to NOT do an ajax request every
Yes that works for the first page - only on that page are the javascript
behaviors rendered.
Basically, we are looking for a way to NOT do an ajax request every time we
check a box - The model object of the check group should be updated when we
a) click the submit button or
b) change the page of
on dev list? You wanna start it?
On Tue, Nov 9, 2010 at 3:57 PM, Igor Vaynberg wrote:
> can we fork this into another thread?
>
> -igor
>
> On Tue, Nov 9, 2010 at 12:46 PM, James Carman
> wrote:
>> Could we introduce the concept of an AutoComponentSource or something,
>> perhaps? A page/compon
can we fork this into another thread?
-igor
On Tue, Nov 9, 2010 at 12:46 PM, James Carman
wrote:
> Could we introduce the concept of an AutoComponentSource or something,
> perhaps? A page/component could potentially have multiple?
>
> On Tue, Nov 9, 2010 at 3:43 PM, Sven Meier wrote:
>> +1 on
Could we introduce the concept of an AutoComponentSource or something,
perhaps? A page/component could potentially have multiple?
On Tue, Nov 9, 2010 at 3:43 PM, Sven Meier wrote:
> +1 on rethinking the auto* stuff together with the proposed queueing.
>
> Sven
>
> Am 09.11.2010 um 21:17 schrieb
+1 on rethinking the auto* stuff together with the proposed queueing.
Sven
Am 09.11.2010 um 21:17 schrieb Igor Vaynberg:
> i wonder if queuing can actually replace icomponentresolver and
> auto-adding. i wonder if after onbeforerender we can do what unqueing
> does now, parse the markup, find a
use AjaxFormChoiceComponentUpdatingBehavior, that one works with Check.
also you can use CheckBox with the ajax behavior instead of CheckGroup/Check
or replace links used by navigator with submit links, there are
factory methods on the navigator.
-igor
On Tue, Nov 9, 2010 at 8:41 AM, Matt Schmi
wtf is with all the stupid and, more importantly, broken analogies? if
you wouldve kept quiet instead of spouting all this garbage i bet a
lot more people wouldve been receptive to the idea. you are digging
your own hole. id like to think we are all practical people, so stick
to practical points. y
i wonder if queuing can actually replace icomponentresolver and
auto-adding. i wonder if after onbeforerender we can do what unqueing
does now, parse the markup, find any missing components, and insert
them. autocomponents and autoadd() is something ive always disliked
because it doesnt work for an
On Tue, Nov 9, 2010 at 12:03 PM, Sven Meier wrote:
> Hi,
>
>> an easy example is:
>>
>> > wicket:id="last"/>
>>
>> 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. t
Hi,
> an easy example is:
>
> wicket:id="last"/>
>
> 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.
I have
I hate to jump into this, but I wanted to pose an assumption and a solution
assuming my assumption is correct ;)
My assumption is that the key issue with the page objects self assembling
into the correct hierarchy based on the HTML is that multiple objects may
use the same wicket ID. If that's no
and that is only because i cant do
component.setAuto(false)
right after i call autoAdd()
else it would just stay there :)
and this is then only done to resolve it once with the first render...
On Tue, Nov 9, 2010 at 20:03, Igor Vaynberg wrote:
> it still wont work for a lot of usecases that
On Tue, Nov 9, 2010 at 12:20 AM, Martin Makundi
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 havi
it still wont work for a lot of usecases that require proper
hierarchy. like a form trying to find form submitting component, etc
-igor
On Tue, Nov 9, 2010 at 10:59 AM, Johan Compagner wrote:
> ok a sample that it also works in with the right parent:
>
> public class HelloWorld extends WebPage i
ok a sample that it also works in with the right parent:
public class HelloWorld extends WebPage implements IComponentResolver {
final Label label;
public HelloWorld()
{
label = new Label("label", new Model()
{
Ok, I think one the main point in Igor's proposal was to overcome this
particular problem in addition to few others:
https://github.com/ivaynberg/wicket/tree/component-queuing
**
Martin
2010/11/9 Johan Compagner :
> textfield.isEnabledInHierachy() will then ofcourse not get to the
> parent it is
On Tue, Nov 9, 2010 at 9:38 AM, Martin Makundi
wrote:
>> The user can queue stuff to the wrong component unknowingly because
>> they won't get an exception.
>
> You will get an exception if you queue explicitly to the wrong
> component. If you don't care about the parent component, it 's their
> c
the queue() method is there in addition to add(), so you dont have to
use it. yes, it is riskier to use under some circumstances because it
is more forgiving then add() - but thats the point i think.
-igor
On Tue, Nov 9, 2010 at 9:41 AM, James Carman wrote:
> On Tue, Nov 9, 2010 at 12:38 PM, Mar
textfield.isEnabledInHierachy() will then ofcourse not get to the
parent it is on.
because its parent is the webpage not the body markupcontainer.
So no this will not resolver from the child to the parent, only the
parent to the child.
On Tue, Nov 9, 2010 at 19:30, Martin Makundi
wrote:
> How w
How will it work if I call get("body").setEnabled(false); and if label
was a textfield? Would the textfield be still enabled?
**
Martin
2010/11/9 Johan Compagner :
> no ofcourse not
> The label will then be gone because the body is gone.
> so the output will be this
>
>
>
> when the body contai
no ofcourse not
The label will then be gone because the body is gone.
so the output will be this
when the body container is not visible
if the label is not visible:
this solution you just can throw everything in the panel or webpage
that is the IComponentResolver for all its childs...
Ju
I think you need to implement the AjaxPagingNavigator#onAjaxEvent method and
add the currentPage component on target.
On Tue, Nov 9, 2010 at 4:20 PM, vp143 wrote:
>
> Thank you both for your responses- I totally forgot about it being dynamic.
>
> However, I have tried both code snippets above bu
Thank you both for your responses- I totally forgot about it being dynamic.
However, I have tried both code snippets above but still no luck.
I printed the current page within the load() method which prints 0 only on
first load. No message is printed when the page numbers from
AjaxPagingNavigator
This does not really nest the components logically, does it?
If you set get("body").setVisible(false) will the label remain visible?
**
Martin
2010/11/9 Johan Compagner :
> Why are we discussing here already that works in wicket 1.4 if you
> really need it?
>
>
> public class HelloWorld extends
Why are we discussing here already that works in wicket 1.4 if you
really need it?
public class HelloWorld extends WebPage implements IComponentResolver {
public HelloWorld()
{
add(new WebMarkupContainer("body"));
add(new Label("label","my label"))
>> Very good point: cleaner code! Finally complex wicket pages will look
>> like their hello-world counterparts.
>
> You're becoming a bit irrational here, Martin. Let's try to stay on
> point. He brings up a valid point and we should respect his opinion,
> much like we're respecting yours. Rem
On Tue, Nov 9, 2010 at 12:43 PM, Martin Makundi
wrote:
>
> So you mean that if a manufacturer manufactures a gun they are not
> conciously making the decision that somebody is getting shot?
>
Ok, I'm officially done with this conversation. I've voiced my
opinion. You apparently aren't open to a
> You're not understanding what I'm saying. I'm saying they're not
> consciously making a *choice*; they're queueing the component to the
> wrong parent on accident, but they aren't getting an exception. This
> can lead to problems later on.
So you mean that if a manufacturer manufactures a gun
On Tue, Nov 9, 2010 at 12:38 PM, Martin Makundi
wrote:
>
> You will get an exception if you queue explicitly to the wrong
> component. If you don't care about the parent component, it 's their
> choie (good or bad) ;)
>
You're not understanding what I'm saying. I'm saying they're not
consciously
> The user can queue stuff to the wrong component unknowingly because
> they won't get an exception.
You will get an exception if you queue explicitly to the wrong
component. If you don't care about the parent component, it 's their
choie (good or bad) ;)
> Then later a markup change could comple
On Tue, Nov 9, 2010 at 12:33 PM, Martin Makundi
wrote:
> Very good point: cleaner code! Finally complex wicket pages will look
> like their hello-world counterparts.
>
You're becoming a bit irrational here, Martin. Let's try to stay on
point. He brings up a valid point and we should respect hi
On Tue, Nov 9, 2010 at 12:29 PM, Martin Makundi
wrote:
>
> I wouldn't call it unknowingly if you are stating it now before the
> feature has been implemented.
>
The user can queue stuff to the wrong component unknowingly because
they won't get an exception. Then later a markup change could
compl
> On the other hand if you only have to do component nesting programmatically
> in case of functional reasons (like security) your code will probably much
> cleaner and you'll realize issues like using the wrong parent faster.
+1
Very good point: cleaner code! Finally complex wicket pages will l
On the other hand if you only have to do component nesting
programmatically in case of functional reasons (like security) your code
will probably much cleaner and you'll realize issues like using the
wrong parent faster.
Instead of:
myComponent.add(child1)
child1.add(child2)
child2.add(child3)
> Again, the point is (regardless of unit tests) that you can
> unknowingly do something that allows stuff to break later quite
> easily.
I wouldn't call it unknowingly if you are stating it now before the
feature has been implemented.
**
Martin
>
> --
The problem is that i am using only AbstractCalendar object, because I need
to use YUI CalendarGroup object and show multiple page calendar in page,
every page has only a few available cells for users to pick date of event.
2010/11/9 Igor Vaynberg
> the value should be available in the formcompo
On Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi
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 something that allows stuff to brea
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(...))
>
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi
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(ne
> 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
>
> -
> T
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi
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...
> 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 inappropri
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg 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 car
> On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
> 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
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 yo
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 wrote:
> On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
> wrote:
>> For security reasons in general, you might want to use:
>>
>> formA.queue(formAstuff);
>> fo
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann
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 oth
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg 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 say
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi
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"?
--
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 wrote:
> On Tue, Nov 9,
> 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 gen
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel wrote:
> On Tue, 9 Nov 2010 10:51:49 -0500
> James Carman wrote:
>
>> On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
>> wrote:
>> > If the component hierarchy can be changed without changing behavior
>> > or semantics, then why are the componen
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 Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg 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
On Tue, Nov 9, 2010 at 7:36 AM, John Owen 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 us
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel 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
Use an dinamic model, ex:
Label currentPage = new Label("currentPage", new
AbstractReadOnlyModel() {
public String getObject() {
return pagination.getPageable().getCurrentPage();
}
});
On Tue, Nov 9, 2010 at 2:04 PM, Vishal Popat wrote:
> Hi all,
>
> 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
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 wrote:
> On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
> wrote:
>>
>> Yeah ids must be unique per each level and ofcourse if you have ma
On Tue, 9 Nov 2010 11:33:31 -0500
James Carman 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" a
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
wrote:
>
> Yeah ids must be unique per each level and ofcourse if you have markup like:
>
>
>
> 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 f
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
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
>> @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 s
>> 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 compone
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel 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
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi
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 us
>> 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 gr
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
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi
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-q
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 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 s
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
chec
> 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 p
On Tue, 9 Nov 2010 18:04:44 +0200
Martin Makundi 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-
> 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
> unde
On Tue, 9 Nov 2010 10:51:49 -0500
James Carman wrote:
> On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
> 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
On Tue, 9 Nov 2010 17:46:13 +0200
Martin Makundi 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
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 hierarch
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) {
..
}
}
Aj
On Tue, Nov 9, 2010 at 10:58 AM, Martin Makundi
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 yo
> 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 h
Hi!
> 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 ti
On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann
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 Wi
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 pos
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
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 :
> On Tue, Nov 9, 2010 at 4:39 PM, Martin Makundi <
> martin.maku...@koodaripalve
> 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
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
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 :
> Hi!
>
> Does have capability to "setOutputMarkupPlaceholderTag" ?
>
> What I mean is t
1 - 100 of 149 matches
Mail list logo
