i've done some work to enable embedding wicket pages in jsp pages. this is
required by us, since we're currently using struts, and can't move all our code
to wicket. i think it is important to enable existing projects to start using
wicket.
the main problems in that
Sure. An example is more than welcome.
Juergen
On 5/9/06, Ittay Dror [EMAIL PROTECTED] wrote:
i've done some work to enable embedding wicket pages in jsp pages. this is
required by us, since we're currently using struts, and can't move all our code
to wicket. i think it is important to
i was just looking at that. i think we messed up a little bit there. now that getinputasarray() is public i made getinput() go through that instead of request parameters directly.-Igor
On 5/8/06, Ittay Dror [EMAIL PROTECTED] wrote:
on the off chance that not only igor is patient with this
It will not be previeable any more.
Juergen
On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
why not a format like this
input type=submit value=wicket:i18n:buttons.save/
or
input type=submit value=wi18n:buttons.save/
-Igor
On 5/8/06, Andrew Berman [EMAIL PROTECTED] wrote:
Hey Guys,
This component is already there:new WebMarkupContainer(imageAlt).add(new AttributeModifier(alt, true, new Resource...):-)MartijnOn 5/9/06,
Andrew Berman [EMAIL PROTECTED] wrote:
Hey Guys,I think adding something to support localized attributes would be a big plus. I know that when Wicket added
why not? in a preview you would get a button with text wicket:i18n:buttons.savethats good for preview since you can see the key!-IgorOn 5/8/06,
Juergen Donnerstag [EMAIL PROTECTED] wrote:
It will not be previeable any more.JuergenOn 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: why not a format
thanx
what about using getConvertedInput and getRawInput rather than directly using
the variables?
Igor Vaynberg wrote:
i was just looking at that. i think we messed up a little bit there. now
that getinputasarray() is public i made getinput() go through that
instead of request parameters
im off to bed, so maybe the night crew can take care of this.-IgorOn 5/8/06, Ittay Dror [EMAIL PROTECTED]
wrote:thanxwhat about using getConvertedInput and getRawInput rather than directly using the variables?
Igor Vaynberg wrote: i was just looking at that. i think we messed up a little bit
foo/pkg/ MyWebApplication.properties MyWebApplication.javafoo/pkg/pages FooPage.properties FooPage.html
FooPage.javaShould work. Can you see if you can reproduce in a wicket quickstart?MartijnOn 5/9/06, Bruno Borges
[EMAIL PROTECTED] wrote:I have changed the TypeValidator message, in several
I guess it depends on what job you are in. It is nice for the person
who has to maintain the properties. If I were a html designer I'd
rather prefer a default text like save or whatever, which btw
applies if no property is found.
Juergen
On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
why
It'll give people choice though. Not everyone cares about
previewability in the same fashion.
Eelco
On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I guess it depends on what job you are in. It is nice for the person
who has to maintain the properties. If I were a html designer I'd
rawinput should also be a string[] but the problem is if we change that then getValue()/getRawInput() and maybe als getModelValue all should also change and that will affect a lot...johan
On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i was just looking at that. i think we messed up a little
yes but the strange this is. if the request starts. All pagemaps are walked over and the session is set to themCan you debug that and tell me why that doesn't happen for you?Look at Session.init() and Session.visitPageMaps
()They should walk over all the attributes in the session and what is a
oh, one last thing.
i think it would be nicer if embedded pages can extend panels. i'm not sure if
it is possible (so when including a url, the panel class will be called)
ittay
Ittay Dror wrote:
ok, this is what i did given the existing wicket code. i'm sure it can
be done better by
i don't see why there should be a getInputAsArray. it seems to me there should
be an 'Object getInput()', which will usually return
getRequest().getParameter(getInputName()), but for some components, that for
some reason require multiple inputs, it will return
Object?ughhThen we have to cast and or check for it everywhere. Because getInput() is used for a lot of things,What it could be is always and String[] but then we just have getInputAsArray()and i guess thats the method we should use as much as possible everywhere.
which we already do for the
currently not. What could be better in your eyes?We will overhaul the converter interface in the next version so that it should be simpler.johanOn 5/9/06,
Bruno Borges [EMAIL PROTECTED] wrote:
This is the only way I know (better: I learned from Wiki/Docs/Examples) on how to use
Hi
Im not sure if this is the intended functionality,
but I belive Ive discovered an oddity or featureJ.
When I use the constructor which also takes a model (ListChoice(dropdown_job,
new Model(),myList, new myRenderer)) my listchoice is no longer displayed as a
dropdown but as a
the problem i see is are we going to check every tag's attribute (wicket component or not) for such a thing? And if it is not a wicket component we make it a special (none raw markup) tag?and if it is a wicket component already we just put a special object in the tags attributes?
johanOn 5/9/06,
Or we use one of these post-processing filters. That way components
might even clear them or insert new ones, and only the resulting
markup will be processed.
Eelco
On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
the problem i see is are we going to check every tag's attribute (wicket
We do something similar for autolinks already. Actually I think there
at least 3 solutions:
1) If no wicket:id is present than replace the attribute on the fly
and add it to the markup stream as if it were RawMarkup. Con: changes
to the properties at runtime are not taken into account. Tags with
I think 1 is much more performant when it isn't a wicket componentbecause then the markup is stored under a locale and that markup is preparsed for everything.Can't be faster then that.3 is by far the worst when it comes done to performance. Because we have to do it everytime for every request
A ListChoice should always be a List instead of a DropDown (for a drop down we have the DropDownChoice)I don't know why you see a difference it shouldn't look at all to the model that holds the selection.It only looks at the choices:
tag.put(size, Math.min(maxRows, getChoices().size()));so i guess
Hello Igor
not sure how iframes behave here, but it is possible to call
javascript functions in one frame, which is defined in another frame,
which then again can do anything with the calling frame. Done this a
couple of years ago (when frames where still en vogue ;), but as it
turned out,
for me, it is hard to distinguish getInput from getInputAsArray. what use cases do you have of the returned array having more than 1 string? if that happens, why not use several components, each assigned an index, and still returning getInput (by getRequest().getParameters(name)[idx]).
still the question remains how random is random ;)On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
just checked it into corethe param looks like this wicket:antiCache=random
-IgorOn 5/8/06,
Bruno Borges
[EMAIL PROTECTED] wrote:This could go to Wicket Core. But before this happens, one note:
The
On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
I think 1 is much more performant when it isn't a wicket component
because then the markup is stored under a locale and that markup is
preparsed for everything.
Can't be faster then that.
That is how WicketMessageTagHandler works today. It
there are several components in html that return multipy entriesfor example ListMultiplyChoice (SELECT tag) or Checkboxes withing the same group.convertedinput and rawinput are 2 completely seperate things.
rawinput really caches the raw string data. So that forms can render themselfs again
3 is by far the worst when it comes done to performance. Because we have to
do it everytime for every request even if there isn't a tag like that.. And if it is then we have to manipulate (string concatting and copying) the buffer And it can only be done when the person does buffer the
Johan Compagner wrote:
there are several components in html that return multipy entries
for example ListMultiplyChoice (SELECT tag) or Checkboxes withing the
same group.
convertedinput and rawinput are 2 completely seperate things.
rawinput really caches the raw string data. So that forms
I solved this some time ago with own preprocessor that replaces
${key} with the value from property files.
I know this is not very wicket-like, but the markup looks much simpler
with ${key} then with wicket:message key=key/wicket:message
-Matej
Igor Vaynberg wrote:
why not? in a preview you
That is also a possibiltyThat we pre process the markup even before the markup parser handles it.Then we just replace all wicket:i18n:key:XX (or whatever we call it) and then parse the markup.johan
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
I solved this some time ago with own
So far I can say it works well for me.
The only problematic (or cumbersome) thing was that I had to make my own
ResourceStreamLocator and ResourceStream to have this done.
Having some kind of preprocessing filters (with methods like
String processString(String) or
InputStream
convertedinput and rawinput are 2 completely seperate things. rawinput really caches the raw string data. So that forms can render
themselfs again without doing any validation or conversion.why not use getInput()? why not have getInput() use rawInput internally, for caching?Thats what getValue()
I found the problem. BIOS... (In portuguese, means: Stupid Ignorant Operating the System)... :)On 5/9/06, Martijn Dashorst
[EMAIL PROTECTED] wrote:
foo/pkg/ MyWebApplication.properties MyWebApplication.javafoo/pkg/pages FooPage.properties FooPage.html
FooPage.javaShould work. Can you see if you
What's the difference between these two components and where they fit better?-- Bruno Borges[EMAIL PROTECTED]Sun Certified Java Programmer for
1.4Sun Certified Web Component Developer for 1.4
Johan Compagner wrote:
still the question remains how random is random ;)
right. maybe one shared atomically increased integer would do better job?
On 5/9/06, *Igor Vaynberg* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
just checked it into core
the param looks like this
The difference is that a validator only does it job when data comes in.A converter also works on data that goes out.And the difference in incomming data isn't that great, they are doing the same thing.Except thata converter throws an conversion exception and that will be a TypeValidator error
Sure it works, but... if Wicket is going to have ${key}... ${something} in htmls, let's go back to JSP 2.0 and use EL... just a thoughtOn 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote:So far I can say it works well for me.
The only problematic (or cumbersome) thing was that I had to make my
Bruno Borges wrote:
This is completely different. ${key} is simply replaced by a string from
property file. No EL, no expressions, no ognl, nothing. Just a simple
string.
Comparing wicket:message key=key/wicket:message
to${key}
which one is simpler?
-Matej
Sure it works, but... if
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.
-Matej
Bruno Borges wrote:
And how should I write if I want to literally output ${key} to the user?
On
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
Johan Compagner wrote: still the question remains how random is random ;)right. maybe one shared atomically increased integer would do better job?System.nanoTime() should do the trick :-)
Martijn
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.
That is true, we don't have something that allow to
hi,
i have a feedback based on javascript. basically, i want to populate a
javascript function's body with all messages, so it will show them one by one.
the final result will be like:
function showFeedback() {
var message;
message += first feedback\n;
message += second
Typically you'd use the validator when you only want to validate
whether the input follows a certain pattern. But if you want a string
to be formatted between input and ouput, such a converter makes sense.
Eelco
On 5/9/06, Bruno Borges [EMAIL PROTECTED] wrote:
What's the difference between
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.
Unfortunately IMarkupFilter does not
Or take a look at what's in wicket.extensions.util.resource and look
at the Slider component in YUI for an example. I think it's cleaner
like that (keep the javascript in seperate files and run some variable
substitution over it).
Eelco
On 5/9/06, Ittay Dror [EMAIL PROTECTED] wrote:
hi,
i
I haven't looked into it deeper, but it sounds to me that we could
make it slightly easier. We already have post processing filters, so
personally I would think we would be consistent to have pre processing
filters too. I know the functionality to do this is there already, but
we might come up
i think millis will do. If you have a request in the same milli second for the same image.Then the image should really be the same, What can possible change in 1 milli! :)johan
On 5/9/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote:
Johan Compagner
Eelco Hillenius wrote:
Or take a look at what's in wicket.extensions.util.resource and look
at the Slider component in YUI for an example. I think it's cleaner
like that (keep the javascript in seperate files and run some variable
substitution over it).
what do you mean by 'variable
Yep. Bruno, It's trivial to make your own component classes - probably
textfields, no? - that have an API that's more to your taste. It's one
of Wicket's main ideas to make creating custom components easy, so why
not make use of that?
Eelco
On 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
System.nanoTime() is @since 1.5, so I don't think it's usable anyway :)
Johan Compagner wrote:
i think millis will do. If you have a request in the same milli second
for the same image.
Then the image should really be the same, What can possible change in 1
milli! :)
johan
On 5/9/06,
Thanks for the feedback, Ive gotten
the basics working but I have two remaining problems:
How
do I filter on reference Objects, not strings
Can
I make my code filter on partial matches as well?
This is my code excerpt so far:
IColumn[] columns = new IColumn[3];
Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.
Oh, stupid me. It
Juergen Donnerstag wrote:
you need to register it. It is not yet activated by default
application.getPageSettings().addComponentResolver(new
FragmentResolver());
Strangely enough I just used fragments over the weekend and didn't have
to set this setting. What confused me was not having to
Sure... I got the message. :)On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yep. Bruno, It's trivial to make your own component classes - probablytextfields, no? - that have an API that's more to your taste. It's one
of Wicket's main ideas to make creating custom components easy, so whynot
ok, i got most of it.
last question: can the template have a way to loop on a list? if not, then how
do you suggest i templatize the messages, so their formatting is kept in the js
file?
thanx,
ittay
Ittay Dror wrote:
Eelco Hillenius wrote:
Or take a look at what's in
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
$${key}? Or whatever you want.
I don't need this behavior to be in wicket core. I'm much more
interested in clean and simple preprocessing filters, something wicket
lacks currently.
-Matej
Yeah, that sounds like a good idea. If we have that
Martijn is writing about localization for Wicket In Action now. I'm
sure he'd appreciate it if someone would write up some notes about how
to do this on the WIKI.
Eelco
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Juergen Donnerstag wrote:
On 5/9/06, Matej Knopp [EMAIL
So are we saying that there is going to be some MarkupFilter to replace whatever the developer decides to use for a localization demarcator?I had another idea. What if wicket:message was enhanced? Would something like this work:
wicket:message key=myKey applyTo=value input type=submit
What I definitively like about the pre-processor/ filter is that it is
very efficient. Only for static messages though, but that's the whole
idea on these special tags/ attributes anyway.
I don't know. If we can reach a consensus on the best way, I'd be okay
with adopting something that works
:) It's not to bluntly stop the discussion or anything. I just that it
might not be obvious to everyone that creating custom components/ a
set of base widgets tailored to your need/ taste works great.
Eelco
On 5/9/06, Bruno Borges [EMAIL PROTECTED] wrote:
Sure... I got the message. :)
On 5/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
What I definitively like about the pre-processor/ filter is that it is
very efficient. Only for static messages though, but that's the whole
idea on these special tags/ attributes anyway.
But it realy shouldn't be a quick fix. IMO we should
The templating function is deliberately kept simple. If you want it's
pretty easy to create your own template thingies using e.g. Velocity
or Freemarker. But in this case, it's probably sufficient to just
concatenate the list yourself and do substitution of one variable
placeholder. Thus: in your
Hi
I am Japanese Wicket user.
I translate three files of Wicket-examples .
FormInput_ja.html
FormInput_ja.properties
FoemInputApplication.properties
see attached file
thanks
wicket-example_ja.tar
Description: Binary data
What encoding (?xml version=1.0 encoding=) did you use for
FormInput_ja.html. My browser shows some rubbish which I don't think
is japanese. It doesn't seem to be UTF-8.
Juergen
On 5/9/06, Takeshi Matsuba [EMAIL PROTECTED] wrote:
Hi
I am Japanese Wicket user.
I translate three files of
Cool! Thanks a lot. One thing: it is advisable to start your page's
markup files with:
?xml version=1.0 encoding=utf-8?
So that the encoding is set properly. If that is not put in the
markup, it renders quite funny on my box :)
Maybe you want to take a look at these buttons too? You can look
I created a CheckboxData type containing a
boolean (checked) and a label.
I created a CheckboxDataPanel whose
constructor takes a CheckboxData object, and which displays a checkbox and the
label each using a PropertyModel built from the Checkbox Data object.
I constructed a ListView
But it realy shouldn't be a quick fix. IMO we should first improve the
general resource chain. Additional an text based filter in between
would be very easy than.
Juergen
Well, we consider you being the markup masta :) I'm certainly not in
favor of a quick fix anytime, anywhere in Wicket.
Never mind! The problem had nothing to do with
Wicket. My error was trying to
delete elements of the very list I was iterating:
for (CheckboxData cbd :
listToBePruned ){
if (
!cbd.isChecked() ) {
listToBePruned.remove(cbd);
}
}
A different looping strategy solved
it. /Frank
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Personally, I find the concept of any sort of templating/text
substitution a little distasteful. Things would start looking like
velocity or JSP and I can't afford the alcohol to make that livable...
Juergen Donnerstag wrote:
On 5/9/06, Eelco
What would be your suggestion on how to localize HTML which contains
plenty of text which needs to be localized?
Juergen
On 5/9/06, Justin Lee [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Personally, I find the concept of any sort of templating/text
substitution
I think this kind of substition is fine. A slippery slope, but as long
as we resist substituting anything else than just static text, we'll
be fine.
Eelco
On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
What would be your suggestion on how to localize HTML which contains
plenty of text
Yeah, it's UTF-8. Don't forget to set the encoding type in your
editor. That's done for Eclipse if you update.
Eelco
On 5/9/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
What encoding (?xml version=1.0 encoding=) did you use for
FormInput_ja.html. My browser shows some rubbish which I
should we rfe for 2.0?-IgorOn 5/9/06, Johan Compagner [EMAIL PROTECTED] wrote:
rawinput should also be a string[] but the problem is if we change that then getValue()/getRawInput() and maybe als getModelValue all should also change and that will affect a lot...
johan
On 5/9/06, Igor Vaynberg
+1 or juergen can come up with a nice way to do it in our Tags introducing a special MessageTag that is just handles like the RawInputTag for tagsthat only consist of a i18n key. And append auto something in the Wicket Component Tag
attribute if it is a wicket component that also has a i18n
Well, it looks that this is not as easy as it seemed to be.
I've made a MarkupFilter that translates the string. But I need
to give it ContainerInfo of current markup resource (same as
WicketMessageTagHandler gets). The problem is that I can't touch markup
(or markup.getResource) in my
well, my concern is to make this automatic.for example:when a component contributes scriptfunc whatever() { }/script through wicket:head that contribution needs to magically merge.
or when a component contributes stylea { color:red; }/style that also has to magically get mergedbut from what i have
this was never meant to be postprocessedusers are not meant to output wicket:i18n:key to the attribute using an attribute modifier and expect it to work.this was only meant as a preprocessing step toloading the markup. after that users are on their own.
of course then we need to figure out where
heh, i think its random enough. how many decimal places does it show? but you guys can do whatever you want of course :)-IgorOn 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote:System.nanoTime
() is @since 1.5, so I don't think it's usable anyway :)Johan Compagner wrote: i think millis will do. If you
On 5/9/06, Michiel Trimpe [EMAIL PROTECTED] wrote:
Thanks for the feedback, I've gotten
the basics working but I have two remaining problems:
How
do I filter on reference Objects, not stringsyou mean in the DropDownChoice you want to get an object reference back?you
If WicketMessageTagHandler can get resource.getContainerInfo(), why my
filter can't?
There's something about this that doesn't make me feel entirely good.
Why can't my filter get this information? Or even better, why can't my
MarkupParser get this information? Is it /that/ internal?
IMHO
Could the FormComponent#clearInput() be made public?
This is my scenario:
* a recipient property on my model object
* a DropDown (that listens to selection change events) lets users select from a list of Recipient beans
* aTextField is bound to the email fieldfor the model object's recipient
you only need to set the setting if the fragment is going to be rendererd by a different component then the one whose markup its defined in.for example, if you were going to use the fragment that is defiend in your page to create a panel that you add to a column inside a datatable - then you have
the flipside is of course that we were able to refactor a ton without breaking too much api. you can argue that 1.2 has a lot of api breaks, but if you compare code in 1.2 to 1.1 they can almost be different frameworks.
-IgorOn 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
If
Yeah, Wicket is not perfect and neither are we. That's why we discuss
here and see whether we can reach common ground. Then everyone will be
happy! :)
Eelco
On 5/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
the flipside is of course that we were able to refactor a ton without
breaking too much
to elaborate a littlelets say we did let you use a setterthen we have to keep a reference to the converter in the Component, so when serialized it is one more object - that almost never changes - that has to be serialized. making components session footprint even bigger.
also if we let you use a
Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.
What I do mind is the (occasional) lack of flexibility and things that
keep me from
Wicket really isn't perfect. But it's really getting closer and closer :)
-Matej
Eelco Hillenius wrote:
Yeah, Wicket is not perfect and neither are we. That's why we discuss
here and see whether we can reach common ground. Then everyone will be
happy! :)
Eelco
On 5/9/06, Igor Vaynberg [EMAIL
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.
Well, not everyone agrees with you. Some
Eelco Hillenius wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.
Well, not everyone
Anyway, I don't want to sound grumpy or bitter. I really do appreciate
all the hard work you guys do on Wicket. Wicket has made an incredible
progress and I really like the way it's heading.
I'm using wicket for almost year and half now and it seems that I'm not
going to abandon it any soon
Eelco Hillenius wrote: On 5/9/06, Matej Knopp
[EMAIL PROTECTED] wrote: Igor Vaynberg wrote: I don't mind API breaks. Not at all. If I touch code that is not a part of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.hey!! i didnt write
It's explained in the javadocs. And check out the YUI projects from
wicket-stuff and like at the Slider component which has an example of
it. Also, see bottom of
http://chillenious.wordpress.com/2006/05/03/wicket-header-contributions-with-behaviors/
Eelco
On 5/9/06, Ittay Dror [EMAIL
thanx, i did look and you do amazing things with wicket
however, i still want to do it as i first suggested. the reason is that the function i
mentioned is not that simple and has a lot of gui logic in it, which i don't
want to move inside my java code.
thanx,
ittay
Eelco Hillenius wrote:
Eelco Hillenius wrote:
On 5/9/06, Matej Knopp [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote:
I don't mind API breaks. Not at all. If I touch code that is not a part
of Stable API, I take the risk of having to change my code when wicket
version changes. I really don't mind.
Well, not everyone
but what is really a problem then i dont understand? all you want to do is write out some _javascript_ based on feedback messages? instead of using a feedbackpanel add a label that writes out the _javascript_ you want. you can get the messages using
Page.getFeedbackMessages()so something like
the FeedbackPanel component has a lot of non-trivial functionality, that makes
it hard to write my own customized version of it. especially, adding other
components, or controlling existing ones is hackish (i have to use
Component.get() and visitChildren)
maybe have FeedbackPanel use a
Igor Vaynberg wrote:
but what is really a problem then i dont understand? all you want to do
is write out some javascript based on feedback messages? instead of
using a feedbackpanel add a label that writes out the javascript you
want. you can get the messages using
give us an html snippet of what you want as the end result and tell us where the components are. it is very difficult to talk on such a huge abstraction level.-IgorOn 5/9/06,
Ittay Dror [EMAIL PROTECTED] wrote:
Igor Vaynberg wrote: but what is really a problem then i dont understand? all you want
1 - 100 of 104 matches
Mail list logo
