Re: [Wicket-user] access to private fields

[Johan Compagner]

Of course, if Java had compile-time MyClass#field syntax, then that
could enforce the visibility and everyone would be happy.




+1!
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Al Maw]

Igor Vaynberg wrote:
> On 7/7/07, *Eelco Hillenius* <[EMAIL PROTECTED] 
> > wrote:
> 
>  > two points:
>  >
>  > this is relatively new, i think it made it in just before
> 1.3-beta1 or
>  > somewhere there
> 
> I think it's been in there for quite a while. But as I never depended
> on it, I wouldn't know.
> 
>  > you didnt know about it, so of course you would be writing
>  > getters/setters
> 
> Heh. My point is that everyone did that on this project, including you
> as far as I can see.
> 
> 
> i havent done any real wicket coding on that for a while though. i have 
> been in the j2me land since this was introduced. on my other projects i 
> use this feature all the time and dont imagine coding wicket without it 
> anymore :)

I'm with Igor on this. The common use-case is indeed for accessing 
private fields of your Page or whatever. With this feature, much 
boilerplate code is removed. We should not make this hard. Please don't 
remove this.

-1

Of course, if Java had compile-time MyClass#field syntax, then that 
could enforce the visibility and everyone would be happy.

Regards,

Al

-- 
Alastair Maw
Wicket-biased blog at http://herebebeasties.com

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Johan Compagner]

i am als -1 on removing this. it won't help a bit
also this feature is already in the PropertyResolver from november last
year.
So already 8 or 9 months in the code base.

johan


On 7/9/07, Matej Knopp <[EMAIL PROTECTED]> wrote:


I'm a strong -1 on removing access to private fields. This wouldn't
really change anything. When someone wants to access private fields,
he/she will do that, with or without PropertyModel.

-Matej

On 7/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> >
> > I've never said saving typing is always bad. As I said in another
post,
> > saving typing at the cost of static type checking sometimes is a
> > justified tradeoff (eg, regex). Just that I've never seen that being
> > done at the cost of exposing implementation details.
>
> see, this is where we disagree. i think putting public setters and
getters
> for things that are really meant to be only private is exposing
> implementation details. if someone goes hunting for a private field -
and
> they do have to go hunting for it unless it is code they wrote - that is
by
> their choice. you havent leaked anything, they went looking and they can
> access it with or without property model.
>
> the securitymanager concern is valid, albeit having a functioning
> securitymanager is a rare occurence. i was going to suggest having an
> application setting to enable this feature in propertymodel, but now
that i
> think about it it can break libraries that were written with this
feature
> being enabled in mind. so i think it is best to simply leave it the way
it
> is - always on.
>
> but, i think what we can do and what is simple and elegant is to
restrict
> access to fields that are declared on the class being introspected -
> ignoring its superclass hierarchy. that way we limit the scope and still
> have it viable for usecases where it is really useful.
>
> -igor
>
>
>
>
-
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Matej Knopp]

We could do the restriction, but then the question will be how
predicable and confusing this behavior will be.

-Matej

On 7/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> >
> > I've never said saving typing is always bad. As I said in another post,
> > saving typing at the cost of static type checking sometimes is a
> > justified tradeoff (eg, regex). Just that I've never seen that being
> > done at the cost of exposing implementation details.
>
> see, this is where we disagree. i think putting public setters and getters
> for things that are really meant to be only private is exposing
> implementation details. if someone goes hunting for a private field - and
> they do have to go hunting for it unless it is code they wrote - that is by
> their choice. you havent leaked anything, they went looking and they can
> access it with or without property model.
>
> the securitymanager concern is valid, albeit having a functioning
> securitymanager is a rare occurence. i was going to suggest having an
> application setting to enable this feature in propertymodel, but now that i
> think about it it can break libraries that were written with this feature
> being enabled in mind. so i think it is best to simply leave it the way it
> is - always on.
>
> but, i think what we can do and what is simple and elegant is to restrict
> access to fields that are declared on the class being introspected -
> ignoring its superclass hierarchy. that way we limit the scope and still
> have it viable for usecases where it is really useful.
>
> -igor
>
>
>
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Matej Knopp]

I'm a strong -1 on removing access to private fields. This wouldn't
really change anything. When someone wants to access private fields,
he/she will do that, with or without PropertyModel.

-Matej

On 7/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> >
> > I've never said saving typing is always bad. As I said in another post,
> > saving typing at the cost of static type checking sometimes is a
> > justified tradeoff (eg, regex). Just that I've never seen that being
> > done at the cost of exposing implementation details.
>
> see, this is where we disagree. i think putting public setters and getters
> for things that are really meant to be only private is exposing
> implementation details. if someone goes hunting for a private field - and
> they do have to go hunting for it unless it is code they wrote - that is by
> their choice. you havent leaked anything, they went looking and they can
> access it with or without property model.
>
> the securitymanager concern is valid, albeit having a functioning
> securitymanager is a rare occurence. i was going to suggest having an
> application setting to enable this feature in propertymodel, but now that i
> think about it it can break libraries that were written with this feature
> being enabled in mind. so i think it is best to simply leave it the way it
> is - always on.
>
> but, i think what we can do and what is simple and elegant is to restrict
> access to fields that are declared on the class being introspected -
> ignoring its superclass hierarchy. that way we limit the scope and still
> have it viable for usecases where it is really useful.
>
> -igor
>
>
>
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Igor Vaynberg]

On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:



I've never said saving typing is always bad. As I said in another post,
saving typing at the cost of static type checking sometimes is a
justified tradeoff (eg, regex). Just that I've never seen that being
done at the cost of exposing implementation details.



see, this is where we disagree. i think putting public setters and getters
for things that are really meant to be only private is exposing
implementation details. if someone goes hunting for a private field - and
they do have to go hunting for it unless it is code they wrote - that is by
their choice. you havent leaked anything, they went looking and they can
access it with or without property model.

the securitymanager concern is valid, albeit having a functioning
securitymanager is a rare occurence. i was going to suggest having an
application setting to enable this feature in propertymodel, but now that i
think about it it can break libraries that were written with this feature
being enabled in mind. so i think it is best to simply leave it the way it
is - always on.

but, i think what we can do and what is simple and elegant is to restrict
access to fields that are declared on the class being introspected -
ignoring its superclass hierarchy. that way we limit the scope and still
have it viable for usecases where it is really useful.

-igor
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Kent Tong]

  gmail.com> writes:

> the reason why we use getters and setters and not public fields is
> because we never know what is going to happen later - and because it
> is hard to refactor public field access into a getter or a setter we
> opt for the more flexible, but more verbous way first.
> 
> with property model this argument does not exist. it first tries to
> look for a getter/setter and if not found defaults to the field
> itself. so a refactoring there - if you are only concerned with
> property models, is to simply put a getter/setter in place.

This is a good point. The only concern left is the use of SecurityManager
that doesn't grant the app the ReflectPermission (probably in a hosting
environment). I think this is a tradeoff that is up to the app developers
to decide (as long as they're informed of this).



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> This is fine and acceptable. What I'd like to find out is what we should
> tell people about this feature:
> 1) You should always use it.
> 2) You shouldn't use it as it is going to be deprecated.
> 3) You should use it only in cases like your NamePanel.

I put a note/ warning in AbstractPropertyModel and PropertyModel. If
you think the warning should be more prominent (imho, it's fine like
this) you're welcome to provide a patch. Also,  you or anyone else
feeling strongly about this topic could write up a WIKI item on it.

By the time we start on 1.4, we can re-evaluate how we think about
this, and whether we should support a different flavor. Please feel
free to open a JIRA issue for this, fix version 1.4 and pointing to
this thread.

Thanks,

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Kent Tong]

  gmail.com> writes:

> you say you are concerned with abuse, but what would this subclass
> solve? those who want to abuse can then just use privatefieldmodel to
> do so.

No. It is designed to work with cases like your NamePanel. That kind
of use is not an abuse (far from it). It would be an abuse only if it 
was used with a UserPanel that displayed a User object passed in for
editing.

> if you are really concerned with abuse then dont use property models
> at all - they are just a shortcut to save typing.

I've never said saving typing is always bad. As I said in another post,
saving typing at the cost of static type checking sometimes is a 
justified tradeoff (eg, regex). Just that I've never seen that being
done at the cost of exposing implementation details.

Therefore, I don't see the use of PropertyModel as an abuse. I think
it is perfectly justifiable example of saving typing at the cost of 
static type checking.

> the other problem is that its a bit late to make the change. its been
> in there since before beta 1, and introducing this new subclass will
> silently break people's code.

This is fine and acceptable. What I'd like to find out is what we should
tell people about this feature:
1) You should always use it.
2) You shouldn't use it as it is going to be deprecated.
3) You should use it only in cases like your NamePanel.



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> the point isnt that they are wicket-specific. the point is that they are
> reusable, so if i take a component you wrote and put it into a panel i am
> writing i dont want to put it into an inconsistent state by calling some
> setter i shouldnt. ive done that before and had to go look into the source
> to see what was going on. that is why if you look at a lot of wicket code i
> wrote i use a lot of inner class models instead of getters/setters. when
> that got annoying i discussed this feature with johan and he put it in. i
> think we did have an announcement about it, but maybe we forgot :|

I'm probably confused with support for public fields then. We've had
that from almost the start. :)

Anyway, I'm convinced now that what we have is good. We can go over
the API documentation to see whether we sufficiently warn people, and
we can see whether there is something we can do to make creating a
custom property model that doesn't allow direct access to private
members a bit easier. I agree with Igor that we shouldn't add a new
class for this in the core project.

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Igor Vaynberg]

On 7/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:


> two points:
>
> this is relatively new, i think it made it in just before 1.3-beta1 or
> somewhere there

I think it's been in there for quite a while. But as I never depended
on it, I wouldn't know.

> you didnt know about it, so of course you would be writing
> getters/setters

Heh. My point is that everyone did that on this project, including you
as far as I can see.



i havent done any real wicket coding on that for a while though. i have been
in the j2me land since this was introduced. on my other projects i use this
feature all the time and dont imagine coding wicket without it anymore :)



- its easier to let the ide do that then write an
> inner class :) so you see - not having this feature leads to bad OO as
> you tend to break encapsulation

Like I said before, I agree. Though calling having a few getters and
setters on component you'd only use for Wicket bad OO is a bit far
fetched imo.



the point isnt that they are wicket-specific. the point is that they are
reusable, so if i take a component you wrote and put it into a panel i am
writing i dont want to put it into an inconsistent state by calling some
setter i shouldnt. ive done that before and had to go look into the source
to see what was going on. that is why if you look at a lot of wicket code i
wrote i use a lot of inner class models instead of getters/setters. when
that got annoying i discussed this feature with johan and he put it in. i
think we did have an announcement about it, but maybe we forgot :|

-igor


Eelco


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> two points:
>
> this is relatively new, i think it made it in just before 1.3-beta1 or
> somewhere there

I think it's been in there for quite a while. But as I never depended
on it, I wouldn't know.

> you didnt know about it, so of course you would be writing
> getters/setters

Heh. My point is that everyone did that on this project, including you
as far as I can see.

> - its easier to let the ide do that then write an
> inner class :) so you see - not having this feature leads to bad OO as
> you tend to break encapsulation

Like I said before, I agree. Though calling having a few getters and
setters on component you'd only use for Wicket bad OO is a bit far
fetched imo.

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[igor . vaynberg]

On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> Would a specialized PropertyModel subclass (eg, PrivateFieldModel) do
> the job?

you say you are concerned with abuse, but what would this subclass
solve? those who want to abuse can then just use privatefieldmodel to
do so.

if you are really concerned with abuse then dont use property models
at all - they are just a shortcut to save typing.

the other problem is that its a bit late to make the change. its been
in there since before beta 1, and introducing this new subclass will
silently break people's code.

-igor

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[igor . vaynberg]

On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> Martijn Dashorst  gmail.com> writes:
>
>
> For a Java bean class, most likely every field is to be read sooner
> or later. According to this argument of speed, we should simply
> use public fields for all Java bean classes? As I said before, I
> don't see why Wicket code is in a special position to have this
> access, while other code (eg, domain code) using that Java bean
> class shouldn't.

the reason why we use getters and setters and not public fields is
because we never know what is going to happen later - and because it
is hard to refactor public field access into a getter or a setter we
opt for the more flexible, but more verbous way first.

with property model this argument does not exist. it first tries to
look for a getter/setter and if not found defaults to the field
itself. so a refactoring there - if you are only concerned with
property models, is to simply put a getter/setter in place.

-igor

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[igor . vaynberg]

On 7/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> Well, just take a look at the project we are working on together. Such
> fields mostly have getters and setters :)

two points:

this is relatively new, i think it made it in just before 1.3-beta1 or
somewhere there

you didnt know about it, so of course you would be writing
getters/setters - its easier to let the ide do that then write an
inner class :) so you see - not having this feature leads to bad OO as
you tend to break encapsulation

-igor

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Kent Tong]

Igor Vaynberg  gmail.com> writes:

> i disagree completely. the most common usecase for this is for components 
> to access their own private fields via property model.
> class namepanel extends formcomponentpanel {  
> private string first;
> private string last;  
> namepanel(..) {   
> add(new textfield("first", new propertymodel(this, "first"));
> ...
> } 
> updatemodel() { 
> getmodel().setobject(first+"  "+last);
>  }
> }

Would a specialized PropertyModel subclass (eg, PrivateFieldModel) do 
the job?

class namepanel extends formcomponentpanel {
  private string first;
  private string last;

  namepanel(..) {
add(new textfield("first", new PrivateFieldModel(this, "first"));
...
   }

  updatemodel() { getmodel().setobject(first+"  "+last); }
}




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Kent Tong]

Martijn Dashorst  gmail.com> writes:

> Like it or not, propertymodels already break encapsulation, the law of
> demeter and refactoring without having to resort to private accessors.
> So if you go all OO, these things should never be used, especially
> since there is a perfect OO alternative:

When using PropertyModel, one does sacrifice static type checking for
better expressive power (using a property name instead of getObject()
plus setObject()). However, the point is that this kind of tradeoff
is not uncommon. For example, regular expression gives us expressive
power, but at the same time we lose static type checking (compare
the regular expression "a{3,5}" to its type safe equivalent 
"new Repeat(new Atom("a"), 3, 5)").

In contrast, directly accessing the private fields of a class in order
to save the work of generating the accessors is not a tradeoff that
I've seen any where.

> According to the best of my knowledge this was implemented because of
> speed. Instead of having to search through methods hooking into the
> fields saves quite some time.

For a Java bean class, most likely every field is to be read sooner
or later. According to this argument of speed, we should simply
use public fields for all Java bean classes? As I said before, I
don't see why Wicket code is in a special position to have this
access, while other code (eg, domain code) using that Java bean 
class shouldn't.




-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Martijn Dashorst]

On 7/7/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> If we accept that 1) is a good reason for allowing private field access,
> then according to the same reasoning, we should always make our fields
> public and thus eliminate the need for getters and setters. As we are
> not going that, so I believe 1) is not a sufficient reason.

I think this is a strawman argument. You make a mosquito an elephant
in one step.
Monkeys like bananas, I like bananas, therefore I am a monkey.

Like it or not, propertymodels already break encapsulation, the law of
demeter and refactoring without having to resort to private accessors.
So if you go all OO, these things should never be used, especially
since there is a perfect OO alternative:

There is nobody preventing you to stop using PropertyModel and
implementing Model.getObject and Model.setObject yourself, providing
refactor safe, accessor only ways to bind your model to your
components. It is just a lot of work. Hell, you could even install a
security manager that prohibits PropertyModel completely.

If you don't like to do that (given the code explosion I can imagine
it), there is a second best alternative: name your fields different
from the bean accessors. Nobody is preventing you to do that either.

According to the best of my knowledge this was implemented because of
speed. Instead of having to search through methods hooking into the
fields saves quite some time.

Martijn

-- 
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> i disagree completely. the most common usecase for this is for components to
> access their own private fields via property model.
>
>  class namepanel extends formcomponentpanel {
>   private string first;
>   private string last;
>
>   namepanel(..) {
> add(new textfield("first", new propertymodel(this, "first"));
> ...
>}
>
>   updatemodel() { getmodel().setobject(first+"  "+last); }
> }
>
> in the above - first and last are private implementation details of the
> panel.  i do not want them exposed via public getters/setters. so in order
> to avoid it i need to write an inner class that implements imodel for every
> field i want to access - no thanks!

Well, just take a look at the project we are working on together. Such
fields mostly have getters and setters :)

Nevertheless, I agree with this case.

> > Theoretically, this could result in people accessing those members
> > directly where they shouldn't. Even if you think that's fine, I doubt
> > whether this is something Wicket should support.
>
> theoretically i can access private fields without wicket as well.
> theoretically i can rewrite the bytecode and turn every private field into
> public. this is a problem of practicality.

I didn't want to mention the but... because I thought my reply was
verbose enough. Of course people can implement anything they want
themselves.

> it is a religious issue, but an undisputable fact is that this feature saves
> a lot of time and verbousity.
>
> now if you want to get clever you can build in a check to see if the model
> is glued to a component whose private fields it is trying to access and try
> and restrict it, but honestly i see no reason to go this far and add
> overhead

Agreed. I didn't bring up the issue, I'm trying to honestly react to
it. Kent has a point when you look at property models working on
regular Java beans, but if you take inner classes/ members etc into
account, we have more than enough reason to want to support this.

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Igor Vaynberg]

On 7/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:


> i think your argument is willfully slanted.  generic manipulation and
> persistence can be good reasons to reach into an implementation which
> otherwise does not wish to expose properties or fields at all.  i
personally
> prefer objects that keep all these details private.  i would hope that
> private accessor methods took precedence over private fields, but
> given that, i think accessors in general are best avoided and it's not
> necessarily good to expose private details simply to allow them to
> be manipulated by a framework such as spring, wicket or hibernate.
> that said, i think the real root of this problem is that java simply
> fails to adequately express the protection attribute granularity that's
> required here.  being able to define new protection attributes that
> limit the visibility of details based on the package (and possibly other
> details like the thread group) of the caller would be the best way and
> at the present time quite impossible.

As much as I agree with you in general, in this particular case, we
provide direct access to private members where you normally (using
straightforward Java/ no introspection) wouldn't have it.



i disagree completely. the most common usecase for this is for components to
access their own private fields via property model.

class namepanel extends formcomponentpanel {
 private string first;
 private string last;

 namepanel(..) {
   add(new textfield("first", new propertymodel(this, "first"));
   ...
  }

 updatemodel() { getmodel().setobject(first+"  "+last); }
}

in the above - first and last are private implementation details of the
panel.  i do not want them exposed via public getters/setters. so in order
to avoid it i need to write an inner class that implements imodel for every
field i want to access - no thanks!



Theoretically, this could result in people accessing those members
directly where they shouldn't. Even if you think that's fine, I doubt
whether this is something Wicket should support.



theoretically i can access private fields without wicket as well.
theoretically i can rewrite the bytecode and turn every private field into
public. this is a problem of practicality.

it is a religious issue, but an undisputable fact is that this feature saves
a lot of time and verbousity.

now if you want to get clever you can build in a check to see if the model
is glued to a component whose private fields it is trying to access and try
and restrict it, but honestly i see no reason to go this far and add
overhead

-igor



Eelco



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> i didn't say that's fine.  it's clearly not.  i was just pointing out
> there's
> another side to this argument because java's protection attributes are
> so coarse grained.  by not supporting this feature, some classes which
> otherwise would have all implementation details private would be forced
> to make those details public JUST to allow wicket to update the model.
> this may be the java way at present, but it's not "fine" either.  this is
> why i suggested a switch to turn this on rather than just abandoning
> the feature.  it's basically a no-win situation where you can choose your
> poison.  i'm just advocating that we let people make that choice for
> themselves.

Well, it's good we have this discussion. I think we never seriously
had it. Or it's my lousy memory again :)

It's kind of a theoretical problem too though imho.

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Jonathan Locke]

i didn't say that's fine.  it's clearly not.  i was just pointing out
there's 
another side to this argument because java's protection attributes are 
so coarse grained.  by not supporting this feature, some classes which 
otherwise would have all implementation details private would be forced 
to make those details public JUST to allow wicket to update the model.  
this may be the java way at present, but it's not "fine" either.  this is 
why i suggested a switch to turn this on rather than just abandoning
the feature.  it's basically a no-win situation where you can choose your
poison.  i'm just advocating that we let people make that choice for
themselves.


Eelco Hillenius wrote:
> 
>> i think your argument is willfully slanted.  generic manipulation and
>> persistence can be good reasons to reach into an implementation which
>> otherwise does not wish to expose properties or fields at all.  i
>> personally
>> prefer objects that keep all these details private.  i would hope that
>> private accessor methods took precedence over private fields, but
>> given that, i think accessors in general are best avoided and it's not
>> necessarily good to expose private details simply to allow them to
>> be manipulated by a framework such as spring, wicket or hibernate.
>> that said, i think the real root of this problem is that java simply
>> fails to adequately express the protection attribute granularity that's
>> required here.  being able to define new protection attributes that
>> limit the visibility of details based on the package (and possibly other
>> details like the thread group) of the caller would be the best way and
>> at the present time quite impossible.
> 
> As much as I agree with you in general, in this particular case, we
> provide direct access to private members where you normally (using
> straightforward Java/ no introspection) wouldn't have it.
> Theoretically, this could result in people accessing those members
> directly where they shouldn't. Even if you think that's fine, I doubt
> whether this is something Wicket should support.
> 
> Eelco
> 
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 

-- 
View this message in context: 
http://www.nabble.com/access-to-private-fields-tf4038948.html#a11475120
Sent from the Wicket - User mailing list archive at Nabble.com.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

> i think your argument is willfully slanted.  generic manipulation and
> persistence can be good reasons to reach into an implementation which
> otherwise does not wish to expose properties or fields at all.  i personally
> prefer objects that keep all these details private.  i would hope that
> private accessor methods took precedence over private fields, but
> given that, i think accessors in general are best avoided and it's not
> necessarily good to expose private details simply to allow them to
> be manipulated by a framework such as spring, wicket or hibernate.
> that said, i think the real root of this problem is that java simply
> fails to adequately express the protection attribute granularity that's
> required here.  being able to define new protection attributes that
> limit the visibility of details based on the package (and possibly other
> details like the thread group) of the caller would be the best way and
> at the present time quite impossible.

As much as I agree with you in general, in this particular case, we
provide direct access to private members where you normally (using
straightforward Java/ no introspection) wouldn't have it.
Theoretically, this could result in people accessing those members
directly where they shouldn't. Even if you think that's fine, I doubt
whether this is something Wicket should support.

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Jonathan Locke]

to give a pseudo-code example of what i mean, imagine something 
like this:

hibernate wicket int getValue() { ... }

where hibernate and wicket are attributes that expose the method
only to org.apache.wicket.** and hibernate's package.  this sort of 
thing is possible in scala, but not java.

in any case, java is broken here and so the choice on this feature is 
not clear.  maybe the best thing is to make private introspection an
application setting that is off by default?  this might be a good idea
for the sake of security anyway.


Jonathan Locke wrote:
> 
> 
> i think your argument is willfully slanted.  generic manipulation and 
> persistence can be good reasons to reach into an implementation which
> otherwise does not wish to expose properties or fields at all.  i
> personally
> prefer objects that keep all these details private.  i would hope that
> private accessor methods took precedence over private fields, but
> given that, i think accessors in general are best avoided and it's not
> necessarily good to expose private details simply to allow them to 
> be manipulated by a framework such as spring, wicket or hibernate.
> that said, i think the real root of this problem is that java simply
> fails to adequately express the protection attribute granularity that's
> required here.  being able to define new protection attributes that 
> limit the visibility of details based on the package (and possibly other
> details like the thread group) of the caller would be the best way and
> at the present time quite impossible.
> 
> 
> Kent Tong wrote:
>> 
>> Hi,
>> 
>> Wicket 1.3 is now allowing PropertyModel to access private fields of the
>> target object. However, I am not sure if this is a recommended practice.
>> There are basically two supporting reasons for this feature:
>> 1) No need to generate boring getters and setters.
>> 2) Hibernate & Spring also support this.
>> 
>> If we accept that 1) is a good reason for allowing private field access, 
>> then according to the same reasoning, we should always make our fields
>> public and thus eliminate the need for getters and setters. As we are
>> not going that, so I believe 1) is not a sufficient reason.
>> 
>> Looking into 2), Hibernate is trying to persist the *implementation* of
>> our class. Therefore, it may need access to its private fields.
>> Therefore,
>> it can be argued that Hibernate is in a special position to be granted
>> such special access. Even so, its official documentation recommends using
>> getters and setters 
>> (http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-pojo-accessors).
>> However, I don't see why PropertyModel (or Wicket code in general) is in
>> such a special position. It is part of the UI and I don't see why UI code
>> should need access to implementation details.
>> 
>> I don't know how Spring access private fields, so I can't comment on that
>> one.
>> 
>> So, is this feature a recommended practice or just a backdoor for those
>> who prefer using public fields?
>> 
>> 
>> 
>> -
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> ___
>> Wicket-user mailing list
>> Wicket-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/access-to-private-fields-tf4038948.html#a11475016
Sent from the Wicket - User mailing list archive at Nabble.com.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Jonathan Locke]

i think your argument is willfully slanted.  generic manipulation and 
persistence can be good reasons to reach into an implementation which
otherwise does not wish to expose properties or fields at all.  i personally
prefer objects that keep all these details private.  i would hope that
private accessor methods took precedence over private fields, but
given that, i think accessors in general are best avoided and it's not
necessarily good to expose private details simply to allow them to 
be manipulated by a framework such as spring, wicket or hibernate.
that said, i think the real root of this problem is that java simply
fails to adequately express the protection attribute granularity that's
required here.  being able to define new protection attributes that 
limit the visibility of details based on the package (and possibly other
details like the thread group) of the caller would be the best way and
at the present time quite impossible.


Kent Tong wrote:
> 
> Hi,
> 
> Wicket 1.3 is now allowing PropertyModel to access private fields of the
> target object. However, I am not sure if this is a recommended practice.
> There are basically two supporting reasons for this feature:
> 1) No need to generate boring getters and setters.
> 2) Hibernate & Spring also support this.
> 
> If we accept that 1) is a good reason for allowing private field access, 
> then according to the same reasoning, we should always make our fields
> public and thus eliminate the need for getters and setters. As we are
> not going that, so I believe 1) is not a sufficient reason.
> 
> Looking into 2), Hibernate is trying to persist the *implementation* of
> our class. Therefore, it may need access to its private fields. Therefore,
> it can be argued that Hibernate is in a special position to be granted
> such special access. Even so, its official documentation recommends using
> getters and setters 
> (http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-pojo-accessors).
> However, I don't see why PropertyModel (or Wicket code in general) is in
> such a special position. It is part of the UI and I don't see why UI code
> should need access to implementation details.
> 
> I don't know how Spring access private fields, so I can't comment on that
> one.
> 
> So, is this feature a recommended practice or just a backdoor for those
> who prefer using public fields?
> 
> 
> 
> -
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> 
> 

-- 
View this message in context: 
http://www.nabble.com/access-to-private-fields-tf4038948.html#a11474981
Sent from the Wicket - User mailing list archive at Nabble.com.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] access to private fields

[Eelco Hillenius]

(http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-pojo-accessors).
> However, I don't see why PropertyModel (or Wicket code in general) is in
> such a special position. It is part of the UI and I don't see why UI code
> should need access to implementation details.
>
> I don't know how Spring access private fields, so I can't comment on that
> one.
>
> So, is this feature a recommended practice or just a backdoor for those
> who prefer using public fields?

That's a good point. I agree with your reasoning. I think we support
that because users asked it (I know, that's kind of a weak argument),
and we probably thought it wouldn't hurt much. I don't think I ever
use it myself tbh.

Maybe we should get rid of this. But let's see what other developers
and users think. Please don't hold back :)

Eelco

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] access to private fields

[Kent Tong]

Hi,

Wicket 1.3 is now allowing PropertyModel to access private fields of the
target object. However, I am not sure if this is a recommended practice.
There are basically two supporting reasons for this feature:
1) No need to generate boring getters and setters.
2) Hibernate & Spring also support this.

If we accept that 1) is a good reason for allowing private field access, 
then according to the same reasoning, we should always make our fields
public and thus eliminate the need for getters and setters. As we are
not going that, so I believe 1) is not a sufficient reason.

Looking into 2), Hibernate is trying to persist the *implementation* of
our class. Therefore, it may need access to its private fields. Therefore,
it can be argued that Hibernate is in a special position to be granted
such special access. Even so, its official documentation recommends using
getters and setters 
(http://www.hibernate.org/hib_docs/v3/reference/en/html/persistent-classes.html#persistent-classes-pojo-accessors).
However, I don't see why PropertyModel (or Wicket code in general) is in
such a special position. It is part of the UI and I don't see why UI code
should need access to implementation details.

I don't know how Spring access private fields, so I can't comment on that
one.

So, is this feature a recommended practice or just a backdoor for those
who prefer using public fields?



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user