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.
there is a setting to make it do so, cant quiet remember where it is right
now.
-igot
On 8/25/07, hhuynh <[EMAIL PROTECTED]> wrote:
>
>
> Thanks for tip. I added this to my pom and it works fine now. Eclipse
> doesn't
> copy non-java files over automatically.
>
>
>
Thanks for tip. I added this to my pom and it works fine now. Eclipse doesn't
copy non-java files over automatically.
src/main/java
**
either the example is broken or your ide does not copy .html files from the
src dir to the classes dir.
-igor
On 8/25/07, hhuynh <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
>
> I've tried out the examples of wicket-contrib-gmap2-examples and got this
> below error. I'm pretty new to Wicket so I'm n
Hi all,
I've tried out the examples of wicket-contrib-gmap2-examples and got this
below error. I'm pretty new to Wicket so I'm not sure where to start
debugging this error.
Anybody has idea?
Thank you,
Hung-
WicketMessage: Markup of type 'html' for component
'wicket.contrib.gmap.GMap2' not f
> 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
I want to have a separate servlet to go along with my wicket application
that can serve streaming files. However, it needs to have access to the
wicket session to know what to stream. I was thinking about using a
WicketSessionFilter to help me do this. I am using wicket as a filter, and
it seems to
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
I am try to see if modal window can be used to pop up a dialog box onto a page
that has been written in php. I essentially want to have a html link on the
older site - that would launch a pop up dialog to my application. want to
avoid first coming to my app and then offering the users a form.
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
Sorry, you are right, I was thinking on Collection, not a String. :(
However, I found where was the problem: while creating Pallete component, I
put the same model as parameters, both for model and choices model.
My mistake, it is 11:30 PM at my place and I'm realy tired. :)
thanks for help,
vatr
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/24/07, Alex Shneyderman <[EMAIL PROTECTED]> wrote:
> I have been reading and re-reading the
> getting started manual, unfortunately it is an extremely incomplete
> document, so it is of a very limited use, although I appreciate the
> intention.
Wicket In Action is available through MEAP now,
are you sure you get an empty string? i dont think that is possible, it
should at least be an empty collection.
-igor
On 8/25/07, Vatroslav <[EMAIL PROTECTED]> wrote:
>
>
> I've tried that, and in that case items are displayed as I want.
> But on submit event, palette.getModelObject() returns e
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
I've tried that, and in that case items are displayed as I want.
But on submit event, palette.getModelObject() returns empty string,
although all items are in the right listbox?!?
vatroslav
that box is populated from the selection model, so make sure the collection
in that model has the selec
that box is populated from the selection model, so make sure the collection
in that model has the selected items
-igor
On 8/25/07, Vatroslav <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
> Is it possible to populate both list boxes on Palette component?
> Or even only right one (Selected)?
> Usually I on
Hi all,
how should i save a page -that I'm modifying from an ajax request originated
at another page- into the session, if possible? The target page is an
iframe nested inside the source one. For the record, I'm doing this trick
not for the pleasure it brings but because of the need to upload fil
Hi,
Is it possible to populate both list boxes on Palette component?
Or even only right one (Selected)?
Usually I only want to change order, and in rare cases to remove some items.
So populating only selected box would be preferable.
Regards,
Vatroslav
--
View this message in context:
http://w
Sorry yes. I agree Wicket has a very elegant solution to giving developers
choice of how to get data between components and model.
Matej Knopp-2 wrote:
>
> But the binding is as pluggable as possible. You can write any IModel
> implementation you want. Think of (Compound)PropertyModel as pure
>
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 requests to bean. But you have to think about
mapping compon
>From a newbie perspective, for what it is worth, say I had a class:
private Object secret;
private String temp;
public getSecret() {return temp;}
private setSecret(Object p) {secret = p;}
So I think I have a read only property secret that comes from temp it is
going to get confusing when Wicket g
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
37 matches
Mail list logo
