gt; Von: Gerolf Seitz [mailto:gerolf.se...@gmail.com]
>> Gesendet: Donnerstag, 26. November 2009 19:36
>> An: users@wicket.apache.org
>> Betreff: Re: PropertyModels *without* strings
>>
>> that's why i was wondering about a lombok based bindgen implementation,
>&
-Ursprüngliche Nachricht-
> Von: Gerolf Seitz [mailto:gerolf.se...@gmail.com]
> Gesendet: Donnerstag, 26. November 2009 19:36
> An: users@wicket.apache.org
> Betreff: Re: PropertyModels *without* strings
>
> that's why i was wondering about a lombok based bindgen imple
that's why i was wondering about a lombok based bindgen implementation,
since
lombok is available as apt processor and eclipse plugin :)
On Thu, Nov 26, 2009 at 5:13 PM, Igor Vaynberg wrote:
> you guys are missing the point. Bindgen is a *standard apt processor*.
> it is not an eclipse plugin. a
you guys are missing the point. Bindgen is a *standard apt processor*.
it is not an eclipse plugin. all major IDEs have support for
annotation processors baked in.
refactoring support is definetely *possible*, but it would require an
actual IDE pliugin.
-igor
On Thu, Nov 26, 2009 at 5:20 AM, Mar
very cool, i like propertyModels more than Compounds :)
NM
On Thu, Nov 26, 2009 at 11:09 AM, James Carman wrote:
> I figured there had to be support for that. Very cool
>
> On Thu, Nov 26, 2009 at 8:14 AM, Johan Compagner
> wrote:
> >
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclip
I figured there had to be support for that. Very cool
On Thu, Nov 26, 2009 at 8:14 AM, Johan Compagner wrote:
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/participants/package-summary.html
>
> On Thu, Nov 26, 2009 a
Ah.. the next big thing, (in) refactoring (bindings?)!!! All glory to
the person that does it.
**
Martin
2009/11/26 Johan Compagner :
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/participants/package-summary.html
>
>
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/participants/package-summary.html
On Thu, Nov 26, 2009 at 13:52, James Carman wrote:
> Refactoring could definitely be supported in IDEA. With the Hibernate
> support, when
On Thu, Nov 26, 2009 at 1:52 PM, James Carman
wrote:
> The configuration files are changed for you. I don't know how eclipse
> works with this kind of
> stuff, but IDEA definitely has hooks for this kind of stuff.
>
> if you refactor->rename a class, you can have eclipse look for the FQCN in
comm
Refactoring could definitely be supported in IDEA. With the Hibernate
support, when you change a property name it will change your mapping
hbm.xml (yes, we still use them) files for you automatically. Same
thing happens with the Spring support. The configuration files are
changed for you. I don
the pro's of this compared to the SafeProperty is that the safe property
needs to generate proxies at runtime so you need CGLIB and you could have
issues with final classes
this is more a develop environment solution which is because of that a bit
nicer.
On Thu, Nov 26, 2009 at 10:53, Maarten Bos
Igor,
Very interesting stuff.
What are the pro's and con's when compared with the SafePropertyModel from
https://issues.apache.org/jira/browse/WICKET-1327 ?
Maarten
On Thu, Nov 26, 2009 at 10:04 AM, Jeremy Thomerson <
jer...@wickettraining.com> wrote:
> Strings do break. Silently. They're th
Strings do break. Silently. They're the silent app killer.
Wouldn't you rather know at compile-time that something is broken? That's
the point of using Java over PHP.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Nov 26, 2009 at 1:28 AM, Martin Makundi <
martin.maku...@koodaripa
On Thu, Nov 26, 2009 at 8:54 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> I would say that refactoring calls for improvement in the bindgen
> approach. Is it theoretically possible to facilitate refactoring with
> bindgen? Is it practically possible to facilitate refactoring w
> suppose you rename Person.getName() to Person.getFullName(). now you
> have to find all places in your code where you have referenced "name"
> as part of a string property expression and change it to "fullName".
If you have a constant PERSON.NAME all you need to do is refactor the
constant and c
On Thu, Nov 26, 2009 at 8:43 AM, Igor Vaynberg wrote:
> i am actually somewhat shocked that someone can look at this and not
> see the value. this fills in a huge gap in java until methods and
> fields become first-class citizens. but, maybe im just weird.
>
>
i was like this > < close to enhancin
the whole point is that strings brake, whether they are constants or not.
eg
add(new Label("parentName", new PropertyModel(person, "parent.name")));
suppose you rename Person.getName() to Person.getFullName(). now you
have to find all places in your code where you have referenced "name"
as part
If refactoring is not supported it is just easier to use string
constants, which do not break.
**
Martin
2009/11/26 Gerolf Seitz :
> as far as i have read, the binding "methods" aren't automatically refactored
> (eg. renamed),
> but you get compiler errors in the code where you use the "old names
as far as i have read, the binding "methods" aren't automatically refactored
(eg. renamed),
but you get compiler errors in the code where you use the "old names". so it
should be
fairly easy to fix your own code (in contrast to some strings)
On Thu, Nov 26, 2009 at 8:04 AM, Giambalvo, Christian <
19 matches
Mail list logo
