Yeah, that's a good point. In fact, we could deprecate them
immediately (1.2); anything that will help users in future
conversions.
Eelco
On 8/19/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> Would depreciating them in 1.3 be worth considering, or is that a step too
> far?
>
> /Gwyn
>
> On 19/08/
Patches item #1543301, was opened at 2006-08-19 18:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1543301&group_id=119783
Please note that this message will contain a full co
based on the fact that there are a number of different reasons i could be
using it in voicetribe, and that is not really a huge project, i'd have to
say, yes. i think this will be used in the majority of non-trivial wicket
applications. this is the reason i would like to see it in core.
Gwyn
* Johan Compagner:
> But i think a converter itself should be even simpler like we have now in
> 2.0
>
> IConverter:
> Object convertToObject(String value, Locale locale);
That's interesting. In Cocoon it is called convertFromString()
instead of convertToObject(), because a [1]ConversionResult
Would depreciating them in 1.3 be worth considering, or is that a step too far?
/Gwyn
On 19/08/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> yip also my sentiment.. Dont break api in 1.3 if it is not really needed (==
> cleanup)
>
> johan
>
>
> On 8/19/06, Eelco Hillenius < [EMAIL PROTECTED]>
* Petr Sakar:
> Use case is
>
> - to be able to generate lot of different forms (basically no
> grafic) with fields which can be added removed dynamically
>
> - maintain uniform look and feel (eg. not to define the html for
> MyTextField on every form again and again
>
> - just define MyTe
Patches item #1543247, was opened at 2006-08-20 00:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1543247&group_id=119783
Please note that this message will contain a full co
In either case, I'd still like to see an article on our quick tour
regarding this component. The article can then mention that the
component is ready for use, but explain the composition in such a way,
that it is trivial for others to persue such 'trivial' components
themselves. This will pave the
I've not doing much actual Wicket coding (as till recently my main
target architechture was WL6.1/JDK1.3.1), so can't comment myself, but
do you think this is likely to be of use in the majority of
(non-trivial) Wicket apps?
If so, I'd support Core, whereas I'd think Extensions might be better
if
yeah, i'm certainly someone who could have written this component too.
only i didn't. and now i've slowly added more and more instances of the
"one time" solution of webmarkupcontainer + simpleattributemodifier.
the only hope here is to have a handy core component. i would have
used that throu
On 8/19/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> -1 for core +1 for extensions
It wouldn't make sense to me to put this in extensions. I'm +1 only
for core. Otherwise I wouldn't bother.
> i think you are actually doing the newbies a disservice by providing this.
> these are elementary conce
Hi ,
can anybody tell me how to use ResourceReference to get button image from
any specific folder.?
I want to create a ImageButton .
yeah, but for simple things just override oncomponenttag() :)but yeah, having a writable map is def a big plus-IgorOn 8/19/06, Johan Compagner
<[EMAIL PROTECTED]> wrote:
i am not pro for ditching thati like the getAttributes() approachBecause they are going to use it for getting stuff in the const
i am not pro for ditching thati like the getAttributes() approachBecause they are going to use it for getting stuff in the constructorso if they can't set it then we get those questions again!And i don't like the attributemodifier anyway for the simple things.
johanOn 8/19/06, Igor Vaynberg <[EMAIL
-1 for core +1 for extensionsi think you are actually doing the newbies a disservice by providing this. these are elementary concepts they need to master.-IgorOn 8/19/06,
Jonathan Locke <[EMAIL PROTECTED]> wrote:
even after reading the counter-arguments, i'm still for this.it's one of those cases
even after reading the counter-arguments, i'm still for this.
it's one of those cases where it's a very common thing to do
(probably MOST web apps have a need to simply modify
a tag attribute) and the alternative for beginners is quite
unintuitive and relies on knowledge they may not have yet.
so
we thought it would be nice to just be able to do public MyComponent(MarkupContainer parent, String id) { super(parent, id); getAttributes().put("class","error");}instead of overriding oncomponenttag or using attributemodifier for simple situations like these.
but maybe we should ditch the
What I haven't understood yet is why this map is modifyable? Why isn't
it just a read-only map. What is wrong with using AttributeModifier
instead.
Juergen
On 8/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Yes (we, igor and me) already had this discussion sometime ago when
> discussing the
im all for putting it into extensions, just not core. and i think in 2.0 we should move requiredtextfield and friends into extensions as well.-IgorOn 8/19/06,
Johan Compagner <[EMAIL PROTECTED]> wrote:
fine by me but we shouldn't go to far with itThings like RequiredTextField which is now only one
fine by me but we shouldn't go to far with itThings like RequiredTextField which is now only one property...But again it is widely used i think so it serves it purpose.And we now also have StatelessLink/Form (
2.0) that also really overrides one method But those are really handy and it is directly
On 8/19/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> Coming in late for the party, but now you see the benefits of
> mailinglists instead of IRC :-)
And I was just about to propose to shut down the lists in favor of the
IRC channel. Or wait...
> I agree with Igor, in the sense that we should
yip also my sentiment.. Dont break api in 1.3 if it is not really needed (== cleanup)johanOn 8/19/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:Yeah. Do it for 2.0. I'm not much in favor of doing this for
1.3. Weshould keep API for 1.3 minimal to make transition from 1.2. to 1.3. -something hopef
hmmmit seems that also my keyboard is not working correctly;)johanOn 8/19/06, Igor Vaynberg <
[EMAIL PROTECTED]> wrote:you mean a keyboard?
-IgorOn 8/19/06, Johan Compagner <
[EMAIL PROTECTED]> wrote:
really? if you press Q it prints A?Strange keyword indeed.johanOn 8/19/06, Frank Bille <
[EMAIL P
Yeah. Do it for 2.0. I'm not much in favor of doing this for 1.3. We
should keep API for 1.3 minimal to make transition from 1.2. to 1.3. -
something hopefully a lot of people will do - will be relatively
painless.
Eelco
On 8/19/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> go ahead, i dare you
you mean a keyboard?-IgorOn 8/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
really? if you press Q it prints A?Strange keyword indeed.johanOn 8/19/06, Frank Bille <
[EMAIL PROTECTED]
> wrote:... and I need to get out of here... it should have been a "Q" and not an "A".
damn keyboardOn 8/19/06,
really? if you press Q it prints A?Strange keyword indeed.johanOn 8/19/06, Frank Bille <[EMAIL PROTECTED]
> wrote:... and I need to get out of here... it should have been a "Q" and not an "A".
damn keyboardOn 8/19/06, Frank Bille <
[EMAIL PROTECTED]> wrote:And someone has already come up with a be
go ahead, i dare you!-IgorOn 8/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
yes if i have to clean up component, then i am really going to clean it up!!Then i will remove pretty much all those silly "redirect" methods..I personally never liked them from day one. Developers need to understand w
yes if i have to clean up component, then i am really going to clean it up!!Then i will remove pretty much all those silly "redirect" methods..I personally never liked them from day one. Developers need to understand what exactly happen.
just calling in a onSubmit() setResponsePage(new MyPage()) o
Yes (we, igor and me) already had this discussion sometime ago when discussing the copy on write map..The problem is we should merge it somehow.. because what if people just added, removed or updated a attribute???
johanOn 8/19/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
we load the attrs into a c
We should. Because now what's probably going on is that the
CopyOnWriteValueMap of component contains reference to map from old markup.
-Matej
Igor Vaynberg wrote:
> we load the attrs into a copy-on-write map - we need to reset the map
> when the markup is reloaded i guess, right johan?
>
> -I
we load the attrs into a copy-on-write map - we need to reset the map when the markup is reloaded i guess, right johan?-IgorOn 8/19/06, Matej Knopp
<[EMAIL PROTECTED]> wrote:I didn't add any attribute modifier.
new TextField(...then I changed markup tothe markup reloaded but until I created new in
always nice to have such a thing.But in the end don't try to squash out the last ms for markup loading/parsingbecause that is only done once in a running system (normally)johan
On 8/19/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I've create some simple performance tests for loading the Markup
I didn't add any attribute modifier.
new TextField(...
then I changed markup to
Sorry, I don't understand it. Can you be a bit more explicit
>
> TextField field = new
> field.add(new AttributeModifier("style", ...)
> or are you talking about Component.setStyle()?
>
> Juergen
>
> On 8/
Neither of these.
I didn't change any of TextFields attributes in java.
I just change the style attribute value in markup.
The markup has been reloaded, but the style attribute of component
stayed the same (rest of the markup was updated).
So the component (textfield in this case, I don't know
And someone has already come up with a better "A" in the FAQ.. The link is now:http://www.wicket-wiki.org.uk/wiki/index.php/FAQs#Which_browsers_has_been_tested_with_Wicket_AJAX
On 8/19/06, Frank Bille <[EMAIL PROTECTED]> wrote:
HeyI have created a FAQ entry in the wiki. But I don't know all the sup
... and I need to get out of here... it should have been a "Q" and not an "A".damn keyboardOn 8/19/06, Frank Bille <
[EMAIL PROTECTED]> wrote:And someone has already come up with a better "A" in the FAQ.. The link is now:
http://www.wicket-wiki.org.uk/wiki/index.php/FAQs#Which_browsers_has_been_tes
Sorry, I don't understand it. Can you be a bit more explicit
TextField field = new
field.add(new AttributeModifier("style", ...)
or are you talking about Component.setStyle()?
Juergen
On 8/19/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> My current use case is that I have an input with a sty
On 8/19/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
So? What's the progress with this? Looking at current AjaxSubmitLink itstill extends WebMarkupContainer...Yeah I know.. thanx bad conscience :)(I'm almost done, just need a little test and to commit it)
- Frank
HeyI have created a FAQ entry in the wiki. But I don't know all the supported browsers. If you know a browser (or a version) which work please add it.
http://www.wicket-wiki.org.uk/wiki/index.php/FAQs#Which_browsers_works_with_Wicket_AJAX- Frank
-
My current use case is that I have an input with a style attribute
(attached to a TextField). When I change the content of the style
attribute, markup is reloaded but new style is not displayed, because
TextField remembers old attribute.
Why is that? Shouldn't it only remember the attributes af
What is the use case for changing Component attributes due to the
associate Markup being re-loaded? Which component attributes should be
reset? To which value? In V2 you may call
MarkupCache.addAfterLoadListener() to register a listener though not
invented for this purpose.
Juergen
On 8/19/06, Ma
Coming in late for the party, but now you see the benefits of
mailinglists instead of IRC :-)
I agree with Igor, in the sense that we should be careful with adding
convenience stuff to core. On the other hand we try to create a
workable framework that actually saves people time.
I think this coul
+1 and this can get on the list for 1.3 as well IMO, or will this
become a big api change?
Martijn
On 8/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> is there any reason why urlfor calls are not synchronized between
> requestcycle and component? i know component had some urlfor that were
> co
Is this a feature or a bug?
-Matej
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application S
So? What's the progress with this? Looking at current AjaxSubmitLink it
still extends WebMarkupContainer...
-Matej
Frank Bille wrote:
> Yup that was the idea ;). Ok anyone else have an opinion?
>
> I still don't see this as an API break. I'll backport it as well.
>
> Frank
>
> On 8/11/06, * J
45 matches
Mail list logo
