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
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
> hmm but how do you get access to the enclosure object? it is only defined in
> the parent. do you mean you would do
> componentInsideEnclosure().getParent() ?
>
> i personally dont, but some people might do, component.getParent() and
> expect a certain parent - but the enclosure is inserted in th
On 8/16/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I've got a first draft ready.- avoid that label.setVisible() called twice not yet implemented. Idon't like the short variable. We'll keep on increasing the flags andvars with every release. What about using the MetaData? Need more mem
if use
I've got a first draft ready.
- avoid that label.setVisible() called twice not yet implemented. I
don't like the short variable. We'll keep on increasing the flags and
vars with every release. What about using the MetaData? Need more mem
if used, but only for very few components.
- partial render:
another issue will be partial renders - we need to render the enclosure as wel as the component - that will make ajax updates more difficult.-IgorOn 8/14/06,
Igor Vaynberg <[EMAIL PROTECTED]> wrote:
woops, minor correction - damn copynpaste
wicket:id="label-container"
class="notify">[[notification
at least you had enough to realize the larger part was missing :)-IgorOn 8/15/06, Matej Knopp <[EMAIL PROTECTED]
> wrote:Eh, stupid me. short is ok of course. Where is my brain when I need it?
Matej Knopp wrote:> with transient short you have same problem as with flags. so you need a> Boolean.>> or
Eh, stupid me. short is ok of course. Where is my brain when I need it?
Matej Knopp wrote:
> with transient short you have same problem as with flags. so you need a
> Boolean.
>
> or a short and a flag (in which case two flags make much more sense,
> because flags are 32 bits now).
>
> -Matej
with transient short you have same problem as with flags. so you need a
Boolean.
or a short and a flag (in which case two flags make much more sense,
because flags are 32 bits now).
-Matej
Igor Vaynberg wrote:
> yeah, basically - to save on space you can have a transient short
>
> and to repr
yeah, basically - to save on space you can have a transient shortand to represent each cached boolean value you need two bits - one to flag if it has been cached and one to store the actual value.-Igor
On 8/15/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Yeah, except that you'd need two flags. Forget
Yeah, except that you'd need two flags. Forget it.
-Matej
Matej Knopp wrote:
> Make it a flag?
>
> -Matej
>
> Igor Vaynberg wrote:
>> i think it would be nice if visible/enabled flags were cached for the
>> duration of request to keep things consistent. we can stash them into a
>> transient v
Make it a flag?
-Matej
Igor Vaynberg wrote:
> i think it would be nice if visible/enabled flags were cached for the
> duration of request to keep things consistent. we can stash them into a
> transient var that gets reset in ondetach() or something. i dont know of
> implications this change mi
i think it would be nice if visible/enabled flags were cached for the duration of request to keep things consistent. we can stash them into a transient var that gets reset in ondetach() or something. i dont know of implications this change might have though.
-IgorOn 8/15/06, Juergen Donnerstag <[EM
Just one comment: label.isVisible() will be called twice if
isVisible() == true. First the wicket:enclosure will call it, and if
true the label itself will as well before rendering the label. Any
simple idea on how to prevent it? Should we prevent it?
Juergen
On 8/15/06, Igor Vaynberg <[EMAIL PRO
it takes just a few lines of code to build, and if we provide it people will want a solution for lets say two attributes and so on. i would rather not open that door - i mean here is the whole thing, count the lines, why cant the users implement this themselves?
class TagModifier extends WebMarkupC
On 8/14/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i think 1 is trivial and should not be part of the core. our api has a
> pretty large surface for the users to learn already and i dont think we need
> to throw such things in.
I would usually agree with that, but in this case I'd be +1 for th
woops, minor correction - damn copynpastewicket:id="label-container"
class="notify">[[notification]]
should be:
[[notification]]
-Igor
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done q
i think 1 is trivial and should not be part of the core. our api has a pretty large surface for the users to learn already and i dont think we need to throw such things in.here is a more indepth example for (2) in case someone didnt get it
w/out wicket:enclosure:[[notification]]
WebMarkupContainer
i've run into a lot of situations developing voicetribe where i'm using
webmarktupcontainers when it seems like it should not be needed.
the code gets verbose and harder to read than it should be.
two quick feature ideas to reduce this:
1. a TagModifier component which extends WebMarkupContaine
21 matches
Mail list logo
