Perhaps to keep us newbies happy a pointer in the javadoc to what to do if
you want vanilla Java Bean behaviour might be handy. I just pulled a face
and put it on my todo list to change.
Anyway, I still can't decide between the verbose solution with tool support
and concise magic without tool sup
in principle a lot of things are doable :)
-igor
On 8/28/07, Kent Tong <[EMAIL PROTECTED]> wrote:
>
>
>
>
> igor.vaynberg wrote:
> >
> > yeah, but you are forgetting that you will also need the compound
> variant,
> > blah blah. before you know it you have replicated a bunch of the
> > hierarchy
igor.vaynberg wrote:
>
> yeah, but you are forgetting that you will also need the compound variant,
> blah blah. before you know it you have replicated a bunch of the
> hierarchy.
> like i said, lets have a vote, propose as many variants of this as you
> want
> and we can see where it goes/what
yeah, but you are forgetting that you will also need the compound variant,
blah blah. before you know it you have replicated a bunch of the hierarchy.
like i said, lets have a vote, propose as many variants of this as you want
and we can see where it goes/what people prefer.
-igor
On 8/28/07, Ke
igor.vaynberg wrote:
>
> cmon, there are plenty of things you can abuse in wicket, or any other
> framework. that is just the nature of the beast. as framework developers
> we
> put out features and hope that our users know how to use them responsibly.
> we cannot continuously cater to newbie u
cmon, there are plenty of things you can abuse in wicket, or any other
framework. that is just the nature of the beast. as framework developers we
put out features and hope that our users know how to use them responsibly.
we cannot continuously cater to newbie users, we have to cater to power
users
igor.vaynberg wrote:
>
> i really dont think this is breaking encapsulation. i will concede that
> there is one case where it can break encapsulation and that is when you
> start out with what is publically accessible and then later you change
> your
> mind and make it completely private, but fo
the processing impart would be nil because we cache a lot of the
information. however forcing wicket annotations on middle tier objects is
not a very good approach.
if people really wanted to do this they can create this kind of annotation
themselves and then install a security manager that would
Hi Igor and Eelco,
Sorry, for interventing in your discussion :)
May java annotations can help us?
Say [EMAIL PROTECTED]/Write
or [EMAIL PROTECTED] or ever to protect all bean.
It would protect the field from accidently access in Wicket models
without any assumption on set/get functions.
