>>
>> Greater power comes with greater responsibility. The problem is it is
>> easy
>> to give people power but hard to make them realize the associated
>> responsibility (when to use that feature). That's why I always suggest
>> to have a PrivateFieldModel class
gt; middle man for access to the component's private fields. So in principle
> it
> is doable.
>
> --
> View this message in context:
> http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12379505
> Sent from the Wicket - User mailing list archive at
can see where it goes/what people prefer.
>
Right. What if we have a SelfCompoundPropertyModel? It can serve as the
middle man for access to the component's private fields. So in principle it
is doable.
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-bin
...
> }
> }
>
>
> igor.vaynberg wrote:
> >
> > we are going about this in circles, so what i propose is that someone
> who
> > really cares about this to put out a vote.
> >
> > -igor
> >
>
> I am fine with it (even though I am
more and more about this issue
in the process).
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12379273
Sent from the Wicket - User mailing list archive at Nabble.com.
-
Due to the non-default nature
> of PrivateFieldModel, only if one is clear about the responsibilities will
> he
> get to power.
> --
> View this message in context:
> http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12364419
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
vide that extra power. Due to the non-default nature
of PrivateFieldModel, only if one is clear about the responsibilities will
he
get to power.
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12364419
Sent f
I haven't used eclipse's 'record a refactoring tool' (tm) yet, but I
hear it works, provided your downstream customers use eclipse, and
then the same version as you do.
Martijn
On 8/28/07, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> On Mon, 27 Aug 2007, Matej Knopp wrote:
> > Have some faith :)
On Mon, 27 Aug 2007, Matej Knopp wrote:
> Have some faith :) The refactoring tools are usually quite powerfull and
> changing public field to property with getter and setter is a trivial thing.
Yep, this solves the problem within an internal API but not
in a published API.
- Timo
On Mon, 27 Aug 2007, Eelco Hillenius wrote:
> Anyway, I think we agree in this thread that first the getters and
> setters should be used, whether they are private or not, and as a
> final resort the member directly. You agree with that?
Yes! This is how it seemed to work up to now, but it's good
On 8/27/07, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
>
> On Sat, 25 Aug 2007, Eelco Hillenius wrote:
> > are discussing here though is quite a different case. If it is no
> > problem that people access members directly, and you think getters and
> > setters are too much bloat, why don't you just
> It's not the first time this poor horse gets flogged
>
> http://www.artima.com/forums/flat.jsp?forum=106&thread=36312
Yep. And it's a long discussion, and it doesn't end in complete agreement.
My position on it is that getters and setters, ugly as they are, and
due to lack of a nicer language
On Sat, 25 Aug 2007, Eelco Hillenius wrote:
> are discussing here though is quite a different case. If it is no
> problem that people access members directly, and you think getters and
> setters are too much bloat, why don't you just make them public then?
Because it's less future proof in the cur
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
>
>
> For the sake of clarity, I think this:
>
> with "public getXXX" and "private setXXX" the property is read only
> with "public getXXX" and "no setXXX" the property is read only
So do I. I think it needs to be fixed. If there is a private setter, we
should use it. Period. Johaaan?!
-Matej
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.
> all i asked johan to do was to tweak property resolver to allow access to
> private stuff. i was under the impression that the property resolver always
> tries to access the getter/setter first, then the field.
>
> half of this thread you are arguing that we shouldnt allow access to private
> fie
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > i completely agree with you. my point is that its been brought up, but
> do
> > you see anyone else jumping in on this conversation and voicing their
> > opinion? you are basically championing this thread because you are a
> core
> > dev.
> i completely agree with you. my point is that its been brought up, but do
> you see anyone else jumping in on this conversation and voicing their
> opinion? you are basically championing this thread because you are a core
> dev. there are other users on this list, if they were just as concerned
>
> first of all the bean spec is _not_ the java way. it is just a spec, widely
> adopted though it is - just like jsf.
Comparing JavaBeans with JSF is plain bs. JavaBeans has been put
forward as a standard patten by SUN from the very first versions of
Java, and it is part of any beginners Java book
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > yes it is the second time this topic comes up out of how many of
> thousands
> > of users there are
> >
> > i dont know. i think this feature is very convenient. it is not
> something
> > you can toggle on and off because 3rd party co
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
>
> Finally, I'd like to hear a good argument why we shouldn't just say:
> if you want to access members directly, just make them public. If you
> want to avoid clutter (i.e. writing getters and setters) and you don't
> care about breaking en
On 8/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> I agree with Igor here. If you are really concerned about protecting private
> fields, your only option is running with a security manager.
> Otherwise there will always be a way around it.
Well, yeah. I know there are ways around it, but active
> yes it is the second time this topic comes up out of how many of thousands
> of users there are
>
> i dont know. i think this feature is very convenient. it is not something
> you can toggle on and off because 3rd party components might be written with
> this in mind. so i would say keep it,
I agree with Igor here. If you are really concerned about protecting private
fields, your only option is running with a security manager. Otherwise there
will always be a way around it. Being able to access private field is
convenient and reduces code clutter. Even though it's not the "cleanest" wa
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> So you write a class with a certain member, but as you don't want
> people to directly access that member, you don't provide an mutator
> method. Someone else takes a look at your class and decides to
> directly access the member using prop
> > I fail the see the logic in that, sorry. Why just not throw any scope
> > limiting away?
>
>
> in this particular case: yes. dont forget that property model is entirely
> about convinience in the first place, and flattening scopes is just another
> part of that convenience :)
So you write a cl
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
>
> I fail the see the logic in that, sorry. Why just not throw any scope
> limiting away?
in this particular case: yes. dont forget that property model is entirely
about convinience in the first place, and flattening scopes is just another
On 8/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > On 8/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > i think that is a foolish argument as you are assuming property model
> > should
> > > only work on _beans_
> > > it is pe
On 8/25/07, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> On Sat, 25 Aug 2007, Igor Vaynberg wrote:
> > always try setter/getter first, if not fallback onto the field.
>
> +1
> Direct field access works typically so I like to omit
> accessor bloat when possible, and if you need any special
> handlin
On 8/25/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> On 8/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > i think that is a foolish argument as you are assuming property model
> should
> > only work on _beans_
> > it is perfectly normal to do something like this:
> >
> > class data { publ
On Sat, 25 Aug 2007, Igor Vaynberg wrote:
> always try setter/getter first, if not fallback onto the field.
+1
Direct field access works typically so I like to omit
accessor bloat when possible, and if you need any special
handling in the accessor just create the accessor method for
it.
If you w
On 8/25/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i think that is a foolish argument as you are assuming property model should
> only work on _beans_
> it is perfectly normal to do something like this:
>
> class data { public String name; public int age; }
Yes, I hope you didn't really think
i think that is a foolish argument as you are assuming property model should
only work on _beans_
it is perfectly normal to do something like this:
class data { public String name; public int age; }
and wicket should work with this. if this data object is a private inner of
something and is only
On 8/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> But the binding is as pluggable as possible. You can write any IModel
> implementation you want. Think of (Compound)PropertyModel as pure
> convenience implementation (that works for 99% usecases). With wicket, you
> don't think of mapping http r
"public getXXX" and "no setXXX" the property is read only
>> >> > > with "no getXXX" and "public setXXX" property is read and write
>> >> >
>> >> > I would say that if the field exists, it should always use that. I
>> >> > think we shou
roperty is read and write
> >> >
> >> > I would say that if the field exists, it should always use that. I
> >> > think we should improve it.
> >> >
> >> > WDYT?
>
; WDYT?
>> >
>> > Eelco
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>
Why couldn't it access the attribute field directly?
-Matej
On 8/25/07, Paolo Di Tommaso <[EMAIL PROTECTED]> wrote:
>
> I agree. If you make the PropertyModel access private getter and setter I
> don't see any reason because it cannot access the attribute field directly
> (when the getter and set
I agree. If you make the PropertyModel access private getter and setter I
don't see any reason because it cannot access the attribute field directly
(when the getter and setter are omitted) .
- Paolo
On 8/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> > Just to be pedantic they are not ign
> Just to be pedantic they are not ignored:
> with "public getXXX" and "private setXXX" the property is read only
> with "public getXXX" and "no setXXX" the property is read only
> with "no getXXX" and "public setXXX" property is read and write
I would say that if the field exists, it should alway
xtField("value", new ModelString() {
>> >> >> public void setString(String p) {
>> >> >> model.setValue(p);
>> >> >> }
>> >> &
public void setString(String p) {
> >> >> model.setValue(p);
> >> >> }
> >> >> public String getString() {
> >> >>
}
>> >> }));
>> >> Is tempting as we would get more tool support in eclipse etc and it is
>> >> more
>> >> obvious what is going on. Obviously the huge downside is that it is
>> much
>> >> mo
Obviously the huge downside is that it is much
> >> more verbose than:
> >> add(new TextField("value"));
> >>
> >> Sorry I'm being so greedy on this forum. Still not switched my thinking
> >> from
> >> the two extremes of
is much
>> more verbose than:
>> add(new TextField("value"));
>>
>> Sorry I'm being so greedy on this forum. Still not switched my thinking
>> from
>> the two extremes of struts and GWT.
>>
>>
>> --
>> View this message
than:
> add(new TextField("value"));
>
> Sorry I'm being so greedy on this forum. Still not switched my thinking from
> the two extremes of struts and GWT.
>
>
> --
> View this message in context:
> http://www.nabble.com/Alt
from
the two extremes of struts and GWT.
--
View this message in context:
http://www.nabble.com/Alternative-to-Wicket-data-binding-tf4322899.html#a12310156
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To un
48 matches
Mail list logo
