Re: Scala-Wicket Help and Advice
Yea,
I have consistently advocated using Scala with strong coding
standards - standards that are actually believed in and enforced.
I have referred to it as OO Scala, Scala which is strong on the
Java-like Object-Oriented features plus functional programming
in-the-small, but refrains from using functional programming
in-the-large, many of Scala's functional goodies and advanced
type capabilities (and if any of these really have to be used, they
should be approved by the group and be documented in detail).
The reasons for Scala and using it with limitation are:
Scala is a better Java and
The use of Scala's advanced features must be controlled so that
code is understandable, maintainable and, most importantly, so that
one can access the existing programmer labor pool and not have to
limit one self to the very small number of FP programmers out there.
Those who advocate the use of Scala's advanced features on large
projects are really advocating that Scala be only a niche language.
Richard
On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:
Hey mate,
I code Java for my day job, and write my fun code in Scala. I just love the
flexibility of Scala combined with the power to use all my existing Java
libraries. That said,
I don't see Scala overcoming Java anytime soon because it offers developers
_too much_ freedom. I had a real bad time using
http://dispatch.databinder.net for a project, because it fully utilized a
lot of Scala features to offer a really shit API. Java makes everyone
conform to a base level while preventing soaring, and it's a base level
that's sane. And when it comes to writing business code, as in Code that
makes money, Scala's freedom doesn't offer overly much compared to Java's
enforced conformity.
Don't get me wrong, I3 Scala, but while half of me wants to use it at
work, the other half is terrified of what the Java developers who write
Spring code like this:
bean id=something class=java.lang.String
constructor-arg index=0
value${someProperty}/value
/constructor-arg
/bean
Would do with the power of Scala at their finger tips. (PS, that's real
Spring code that I saw (and refactored) today.)
On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
richard.ember...@gmail.com wrote:
I originally mentioned the Kuhn book in the context of the politics of
change. Altering the focus, you brought up *the truth* as the view
held by those resisting change, which I believe is not the larger
insight to be gained from his book. It is still my contention that my
original interpretation is valid; Scala faces resistance to change and
the structure of that resistance, maps into those structures
identified by Kuhn.
Using a term you earlier used, I think it would be naive to believe
that entrenched business forces will stop the emergence of a new,
major development language. Such forces were aligned against C, C++
and Java, but the forces were overcome. In each case, rational
examination of the languages revealed advantages as well as
non-rational forces, such as Sun's marketing and glitter in the case
of Java, strengthening the prospects of the language's adaption. I
hope we can both agree that change will come.
But, I do not believe the change will be revolutionary but, rather,
evolutionary. A language that evolves from an existing ecosystem has a
much greater likelihood of becoming significant than a green field
language.
I paint and sculpt as well as do mathematics and physics and, for me,
language selection is far closer to math and physics than to the play
of colors or shape and form. I, thus, do not agree that choosing a
programming language is an exercise in artistry, but rather, its a
more rational process. And, if beauty is involved, then it is
scientific beauty and not artistic beauty. Are you Picasso? Maybe
even Mondrian? Hopefully, not Pollock.
Concerning the languages you listed as the way forward, an important
criteria must be: where are the programmers coming from? One can wait
for a new generation or one can see if any existing programmers will
migrate from their current language to a new language. Some language
usages from the web:
Java 18%
C16%
C++ 9%
Python6%
C#6%
Objective-C 3%
Ruby 2%
Lisp 1%
Scheme ~0.5%
Haskell ~0.3%
Scala~0.3%
Eiffel0.1%
Clojure ~0.0%
So, where might future Haskell or Clojure or Eiffel or Scala
programmers come from?
# So, what about Eiffel?
Eiffel (with DbC, design by contract) is a 25 year old language and
its usage stats are down in the noise - well below Scala, Clojure and
Haskell - and showing its age. Hard to see a ground swell of C or Java
programmers switching to Eiffel.
Eiffel's grasp exceeded what could be supported; its notion of
contract was so big, it was hard to find a wrapper around it all.
Category Theory may provide for a pragmatic approach to reasoning
Re: Scala-Wicket Help and Advice
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
Scala maybe needs a bit more syntactical canonicity?
**
Martin
2011/1/19 richard emberson richard.ember...@gmail.com:
Yea,
I have consistently advocated using Scala with strong coding
standards - standards that are actually believed in and enforced.
I have referred to it as OO Scala, Scala which is strong on the
Java-like Object-Oriented features plus functional programming
in-the-small, but refrains from using functional programming
in-the-large, many of Scala's functional goodies and advanced
type capabilities (and if any of these really have to be used, they
should be approved by the group and be documented in detail).
The reasons for Scala and using it with limitation are:
Scala is a better Java and
The use of Scala's advanced features must be controlled so that
code is understandable, maintainable and, most importantly, so that
one can access the existing programmer labor pool and not have to
limit one self to the very small number of FP programmers out there.
Those who advocate the use of Scala's advanced features on large
projects are really advocating that Scala be only a niche language.
Richard
On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:
Hey mate,
I code Java for my day job, and write my fun code in Scala. I just love
the
flexibility of Scala combined with the power to use all my existing Java
libraries. That said,
I don't see Scala overcoming Java anytime soon because it offers
developers
_too much_ freedom. I had a real bad time using
http://dispatch.databinder.net for a project, because it fully utilized a
lot of Scala features to offer a really shit API. Java makes everyone
conform to a base level while preventing soaring, and it's a base level
that's sane. And when it comes to writing business code, as in Code that
makes money, Scala's freedom doesn't offer overly much compared to Java's
enforced conformity.
Don't get me wrong, I3 Scala, but while half of me wants to use it at
work, the other half is terrified of what the Java developers who write
Spring code like this:
bean id=something class=java.lang.String
constructor-arg index=0
value${someProperty}/value
/constructor-arg
/bean
Would do with the power of Scala at their finger tips. (PS, that's real
Spring code that I saw (and refactored) today.)
On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
richard.ember...@gmail.com wrote:
I originally mentioned the Kuhn book in the context of the politics of
change. Altering the focus, you brought up *the truth* as the view
held by those resisting change, which I believe is not the larger
insight to be gained from his book. It is still my contention that my
original interpretation is valid; Scala faces resistance to change and
the structure of that resistance, maps into those structures
identified by Kuhn.
Using a term you earlier used, I think it would be naive to believe
that entrenched business forces will stop the emergence of a new,
major development language. Such forces were aligned against C, C++
and Java, but the forces were overcome. In each case, rational
examination of the languages revealed advantages as well as
non-rational forces, such as Sun's marketing and glitter in the case
of Java, strengthening the prospects of the language's adaption. I
hope we can both agree that change will come.
But, I do not believe the change will be revolutionary but, rather,
evolutionary. A language that evolves from an existing ecosystem has a
much greater likelihood of becoming significant than a green field
language.
I paint and sculpt as well as do mathematics and physics and, for me,
language selection is far closer to math and physics than to the play
of colors or shape and form. I, thus, do not agree that choosing a
programming language is an exercise in artistry, but rather, its a
more rational process. And, if beauty is involved, then it is
scientific beauty and not artistic beauty. Are you Picasso? Maybe
even Mondrian? Hopefully, not Pollock.
Concerning the languages you listed as the way forward, an important
criteria must be: where are the programmers coming from? One can wait
for a new generation or one can see if any existing programmers will
migrate from their current language to a new language. Some language
usages from the web:
Java 18%
C 16%
C++ 9%
Python 6%
C# 6%
Objective-C 3%
Ruby 2%
Lisp 1%
Scheme ~0.5%
Haskell ~0.3%
Scala ~0.3%
Eiffel0.1%
Clojure ~0.0%
So, where might future
Re: Scala-Wicket Help and Advice
Flexible syntax is a big part of it, but combined with operator override,
it's a potential hole for understanding.
They will never officially do that because one big use-case for scala is
DSLs, in which this is an advantage (and the main scala team just got a
reasonably large funding from a group that is interested in using Scala as
DSLs).
I'm with Richard, only strict coding standards will move Scala into
mainstream (ok ok, there are a FEW mainstream projects, but I mean
MAINmainstream). I'm not sure why it was never officially proposed yet...
[]s Gus
On Wed, Jan 19, 2011 at 7:22 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
Scala maybe needs a bit more syntactical canonicity?
**
Martin
2011/1/19 richard emberson richard.ember...@gmail.com:
Yea,
I have consistently advocated using Scala with strong coding
standards - standards that are actually believed in and enforced.
I have referred to it as OO Scala, Scala which is strong on the
Java-like Object-Oriented features plus functional programming
in-the-small, but refrains from using functional programming
in-the-large, many of Scala's functional goodies and advanced
type capabilities (and if any of these really have to be used, they
should be approved by the group and be documented in detail).
The reasons for Scala and using it with limitation are:
Scala is a better Java and
The use of Scala's advanced features must be controlled so that
code is understandable, maintainable and, most importantly, so that
one can access the existing programmer labor pool and not have to
limit one self to the very small number of FP programmers out there.
Those who advocate the use of Scala's advanced features on large
projects are really advocating that Scala be only a niche language.
Richard
On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:
Hey mate,
I code Java for my day job, and write my fun code in Scala. I just love
the
flexibility of Scala combined with the power to use all my existing Java
libraries. That said,
I don't see Scala overcoming Java anytime soon because it offers
developers
_too much_ freedom. I had a real bad time using
http://dispatch.databinder.net for a project, because it fully utilized
a
lot of Scala features to offer a really shit API. Java makes everyone
conform to a base level while preventing soaring, and it's a base level
that's sane. And when it comes to writing business code, as in Code
that
makes money, Scala's freedom doesn't offer overly much compared to
Java's
enforced conformity.
Don't get me wrong, I3 Scala, but while half of me wants to use it at
work, the other half is terrified of what the Java developers who write
Spring code like this:
bean id=something class=java.lang.String
constructor-arg index=0
value${someProperty}/value
/constructor-arg
/bean
Would do with the power of Scala at their finger tips. (PS, that's real
Spring code that I saw (and refactored) today.)
On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
richard.ember...@gmail.com wrote:
I originally mentioned the Kuhn book in the context of the politics of
change. Altering the focus, you brought up *the truth* as the view
held by those resisting change, which I believe is not the larger
insight to be gained from his book. It is still my contention that my
original interpretation is valid; Scala faces resistance to change and
the structure of that resistance, maps into those structures
identified by Kuhn.
Using a term you earlier used, I think it would be naive to believe
that entrenched business forces will stop the emergence of a new,
major development language. Such forces were aligned against C, C++
and Java, but the forces were overcome. In each case, rational
examination of the languages revealed advantages as well as
non-rational forces, such as Sun's marketing and glitter in the case
of Java, strengthening the prospects of the language's adaption. I
hope we can both agree that change will come.
But, I do not believe the change will be revolutionary but, rather,
evolutionary. A language that evolves from an existing ecosystem has a
much greater likelihood of becoming significant than a green field
language.
I paint and sculpt as well as do mathematics and physics and, for me,
language selection is far closer to math and physics than to the play
of colors or shape and form. I, thus, do not agree that choosing a
programming language is an exercise in artistry, but rather, its a
more rational
Re: [vote] retry: release wicket 1.5-rc1
I've clicked over my application and couldn't find any issue, so I'm (non-binding) +1. Regards, Peter 2011-01-18 19:16 keltezéssel, Igor Vaynberg írta: this is the second vote to release wicket 1.5-rc1. all vote-blocking issues previously reported have been fixed branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ maven repo: https://repository.apache.org/content/repositories/orgapachewicket-044/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC this vote ends Friday, January 21 at 10:00am GMT-8 please test the release and offer your vote cheers, -igor
Re: Scala-Wicket Help and Advice
Yeah.. scala is like javazcribl ;)
2011/1/19 Gustavo Hexsel ghex...@gmail.com:
Flexible syntax is a big part of it, but combined with operator override,
it's a potential hole for understanding.
They will never officially do that because one big use-case for scala is
DSLs, in which this is an advantage (and the main scala team just got a
reasonably large funding from a group that is interested in using Scala as
DSLs).
I'm with Richard, only strict coding standards will move Scala into
mainstream (ok ok, there are a FEW mainstream projects, but I mean
MAINmainstream). I'm not sure why it was never officially proposed yet...
[]s Gus
On Wed, Jan 19, 2011 at 7:22 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
Scala maybe needs a bit more syntactical canonicity?
**
Martin
2011/1/19 richard emberson richard.ember...@gmail.com:
Yea,
I have consistently advocated using Scala with strong coding
standards - standards that are actually believed in and enforced.
I have referred to it as OO Scala, Scala which is strong on the
Java-like Object-Oriented features plus functional programming
in-the-small, but refrains from using functional programming
in-the-large, many of Scala's functional goodies and advanced
type capabilities (and if any of these really have to be used, they
should be approved by the group and be documented in detail).
The reasons for Scala and using it with limitation are:
Scala is a better Java and
The use of Scala's advanced features must be controlled so that
code is understandable, maintainable and, most importantly, so that
one can access the existing programmer labor pool and not have to
limit one self to the very small number of FP programmers out there.
Those who advocate the use of Scala's advanced features on large
projects are really advocating that Scala be only a niche language.
Richard
On 01/18/2011 11:02 PM, Liam Clarke-Hutchinson wrote:
Hey mate,
I code Java for my day job, and write my fun code in Scala. I just love
the
flexibility of Scala combined with the power to use all my existing Java
libraries. That said,
I don't see Scala overcoming Java anytime soon because it offers
developers
_too much_ freedom. I had a real bad time using
http://dispatch.databinder.net for a project, because it fully utilized
a
lot of Scala features to offer a really shit API. Java makes everyone
conform to a base level while preventing soaring, and it's a base level
that's sane. And when it comes to writing business code, as in Code
that
makes money, Scala's freedom doesn't offer overly much compared to
Java's
enforced conformity.
Don't get me wrong, I3 Scala, but while half of me wants to use it at
work, the other half is terrified of what the Java developers who write
Spring code like this:
bean id=something class=java.lang.String
constructor-arg index=0
value${someProperty}/value
/constructor-arg
/bean
Would do with the power of Scala at their finger tips. (PS, that's real
Spring code that I saw (and refactored) today.)
On Tue, Jan 18, 2011 at 5:33 PM, richard emberson
richard.ember...@gmail.com wrote:
I originally mentioned the Kuhn book in the context of the politics of
change. Altering the focus, you brought up *the truth* as the view
held by those resisting change, which I believe is not the larger
insight to be gained from his book. It is still my contention that my
original interpretation is valid; Scala faces resistance to change and
the structure of that resistance, maps into those structures
identified by Kuhn.
Using a term you earlier used, I think it would be naive to believe
that entrenched business forces will stop the emergence of a new,
major development language. Such forces were aligned against C, C++
and Java, but the forces were overcome. In each case, rational
examination of the languages revealed advantages as well as
non-rational forces, such as Sun's marketing and glitter in the case
of Java, strengthening the prospects of the language's adaption. I
hope we can both agree that change will come.
But, I do not believe the change will be revolutionary but, rather,
evolutionary. A language that evolves from an existing ecosystem has a
much greater likelihood of becoming significant than a green field
language.
I paint and sculpt as well as do mathematics and physics and, for me,
language selection is far closer to math and physics than to the play
of colors or shape and form. I, thus, do not agree that choosing
Re: Scala-Wicket Help and Advice
What about rewriting wicket into most wonderful tight functional scala style?
def : webserver {
homepage,
logoutpage,
onlinestore,
}
...
;)
**
Martin
2011/1/19 James Carman ja...@carmanconsulting.com:
I believe this conversation has gone enough off-course that it no
longer belongs on this mailing list. We're not discussing anything
related to Wicket anymore.
On Wed, Jan 19, 2011 at 11:57 AM, richard emberson
richard.ember...@gmail.com wrote:
On 01/19/2011 07:22 AM, Martin Makundi wrote:
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
I guess concerning HTML, I would say that it did not have a good
enough spec soon enough and, of course, MS did whatever they wanted
anyway.
Scala has a very, very detailed spec (do not try to learn the
language by reading the spec first).
Scala also has the incredible advantage that the Scala team
can make changes that are not backward compatible, which is to
say, Scala has had a long gestation period.
This advantage was particularly useful in going from the 2.7 to 2.8
releases where the whole collection framework was redone. They are
finding out what works best and folding those changes back into the
language. This will slow down with time (I expect the collection
re-write is the last super big change).
Scala maybe needs a bit more syntactical canonicity?
I agree, languages have multiple ways of doing things:
while-loop and for-loops
i++ vs i += 1 vs i = i + 1 (Scala does not support i++)
First, Scala is both OO and FP, so there are generally a
couple of approaches - one that looks like Java and one that
is more pipelined, data flowing through functions.
So, it is true that Scala allows one to be creative!?.
Some of this comes from the vastly richer set of capabilities
associated with the collection classes. In Java one has
Iterator while in Scala there is a whole lot of extra
standard methods.
Just yesterday while working on my NIST RBAC code, I had to
decide how to check access rights in a test class:
Does a Session have a given Permission, where
Roles are in a Set and RolesToPerm is a Map from Role to Permission:
def checkAccess(session: Session, perm: Permission): Boolean = {
// version 0, very Java-like, never considered
for (role - session.getRoles) {
val pOp = roleToPerms.get(role)
if (permOp.isDefined)
if (permOp.get == perm) return true
}
false
// or version 1, handling Option the Scala-way
for (role - session.getRoles) {
roleToPerms.get(role) match {
case Some(p) = if (p == perm) return true
case None = // ignore
}
}
false
// or version 2, rather more functional
sesson.getRoles.foldLeft(false) { _ || roleToPerms.get(_).getOrElse(null)
== perm }
}
The first two versions are not too hard to understand, but the last
one, unless you know what foldLeft does, is, I imagine, opaque to most
Java programmers.
[foldLeft sets the result value with an initial value, false, and
then iterates over the values of the container, roles, performing
the operation, ||, creating a new result value on each iteration
where the first _ is the current result value and the second _ is
the value from the container. getOrElse returns the value looked up
from roleToPerms and, if it does not exist, returns null. Lastly,
the iteration stops when the first true value, == perm is true;
the normal || shortcutting.]
That said, I consider the code to be functional
programming in-the-small, a single line of code and, ultimately, more
understandable (and more maintainable) than either of the proceeding
versions. [There maybe a better way to pipeline the evaluation, this
is just what I did.]
I have very mixed feelings about DSLs. If every programmer in your
project creates their own DSLs for their own section or, even worse,
per class, then DSLs are very bad; less understandable code, a
maintenance problem and a barrier to getting new hires up to speed.
On the other hand, if a project controls the use of DSLs and they
are well documented, they could (not will be, but could) be a boon
rather than a bust.
**
Martin
2011/1/19 richard embersonrichard.ember...@gmail.com:
Yea,
I have consistently advocated using Scala with strong coding
standards - standards that are actually believed in and enforced.
I have referred to it as OO Scala, Scala which is strong on the
Java-like Object-Oriented features plus functional programming
in-the-small, but refrains from using functional programming
in-the-large, many of Scala's functional goodies and advanced
type capabilities (and if any of these really have to be used, they
should be
Re: Scala-Wicket Help and Advice
Don't get me wrong, I'm all about seeing a Wicket-like Scala-based
project (and would contribute to it), but that's not what we've been
debating here lately on this thread. If you guys want to talk about
coming up with a from-the-ground-up Scala-based, Wicket-inspired
project, then I'm all ears and think we should start putting something
in github or something.
On Wed, Jan 19, 2011 at 12:09 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
What about rewriting wicket into most wonderful tight functional scala style?
def : webserver {
homepage,
logoutpage,
onlinestore,
}
...
;)
**
Martin
2011/1/19 James Carman ja...@carmanconsulting.com:
I believe this conversation has gone enough off-course that it no
longer belongs on this mailing list. We're not discussing anything
related to Wicket anymore.
On Wed, Jan 19, 2011 at 11:57 AM, richard emberson
richard.ember...@gmail.com wrote:
On 01/19/2011 07:22 AM, Martin Makundi wrote:
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
I guess concerning HTML, I would say that it did not have a good
enough spec soon enough and, of course, MS did whatever they wanted
anyway.
Scala has a very, very detailed spec (do not try to learn the
language by reading the spec first).
Scala also has the incredible advantage that the Scala team
can make changes that are not backward compatible, which is to
say, Scala has had a long gestation period.
This advantage was particularly useful in going from the 2.7 to 2.8
releases where the whole collection framework was redone. They are
finding out what works best and folding those changes back into the
language. This will slow down with time (I expect the collection
re-write is the last super big change).
Scala maybe needs a bit more syntactical canonicity?
I agree, languages have multiple ways of doing things:
while-loop and for-loops
i++ vs i += 1 vs i = i + 1 (Scala does not support i++)
First, Scala is both OO and FP, so there are generally a
couple of approaches - one that looks like Java and one that
is more pipelined, data flowing through functions.
So, it is true that Scala allows one to be creative!?.
Some of this comes from the vastly richer set of capabilities
associated with the collection classes. In Java one has
Iterator while in Scala there is a whole lot of extra
standard methods.
Just yesterday while working on my NIST RBAC code, I had to
decide how to check access rights in a test class:
Does a Session have a given Permission, where
Roles are in a Set and RolesToPerm is a Map from Role to Permission:
def checkAccess(session: Session, perm: Permission): Boolean = {
// version 0, very Java-like, never considered
for (role - session.getRoles) {
val pOp = roleToPerms.get(role)
if (permOp.isDefined)
if (permOp.get == perm) return true
}
false
// or version 1, handling Option the Scala-way
for (role - session.getRoles) {
roleToPerms.get(role) match {
case Some(p) = if (p == perm) return true
case None = // ignore
}
}
false
// or version 2, rather more functional
sesson.getRoles.foldLeft(false) { _ || roleToPerms.get(_).getOrElse(null)
== perm }
}
The first two versions are not too hard to understand, but the last
one, unless you know what foldLeft does, is, I imagine, opaque to most
Java programmers.
[foldLeft sets the result value with an initial value, false, and
then iterates over the values of the container, roles, performing
the operation, ||, creating a new result value on each iteration
where the first _ is the current result value and the second _ is
the value from the container. getOrElse returns the value looked up
from roleToPerms and, if it does not exist, returns null. Lastly,
the iteration stops when the first true value, == perm is true;
the normal || shortcutting.]
That said, I consider the code to be functional
programming in-the-small, a single line of code and, ultimately, more
understandable (and more maintainable) than either of the proceeding
versions. [There maybe a better way to pipeline the evaluation, this
is just what I did.]
I have very mixed feelings about DSLs. If every programmer in your
project creates their own DSLs for their own section or, even worse,
per class, then DSLs are very bad; less understandable code, a
maintenance problem and a barrier to getting new hires up to speed.
On the other hand, if a project controls the use of DSLs and they
are well documented, they could (not will be, but could) be a boon
rather than a bust.
**
Martin
2011/1/19 richard embersonrichard.ember...@gmail.com:
Re: [vote] retry: release wicket 1.5-rc1
+1 Checked the quickstart, random wicket-examples. No major issues. Problems: - niceurl example doesn't load its css properly after some navigation at first load everything is ok but loading it later (after checking other apps) for some reason is broken reproduced with Chrome 10.x and FF3.6.14pre (wasn't able to reproduce with FF 4.0b10pre and Opera 11) - multiupload fails with: Caused by: java.lang.IllegalArgumentException: 'bytes' cannot be negative. at org.apache.wicket.util.lang.Bytes.init(Bytes.java:111) at org.apache.wicket.util.lang.Bytes.bytes(Bytes.java:124) at org.apache.wicket.devutils.inspector.SessionSizeModel.load(SessionSizeModel.java:36) at org.apache.wicket.devutils.inspector.SessionSizeModel.load(SessionSizeModel.java:24) at org.apache.wicket.model.LoadableDetachableModel.getObject(LoadableDetachableModel.java:119) at org.apache.wicket.devutils.debugbar.SessionSizeDebugPanel$2.getObject(SessionSizeDebugPanel.java:75) at org.apache.wicket.devutils.debugbar.SessionSizeDebugPanel$2.getObject(SessionSizeDebugPanel.java:79) at org.apache.wicket.Component.getDefaultModelObject(Component.java:1675) at org.apache.wicket.Component.getDefaultModelObjectAsString(Component.java:1702) at org.apache.wicket.markup.html.basic.Label.onComponentTagBody(Label.java:113) at org.apache.wicket.markup.html.panel.DefaultMarkupSourcingStrategy.onComponentTagBody(DefaultMarkupSourcingStrategy.java:69) at org.apache.wicket.Component.internalRenderComponent(Component.java:2502) ... there is something wrong in devutils .. single file upload has no such problem - authentication1 - the password field is not visible/rendered in Chrome 10.x and FF4 (ok in FF 3.6 and Opera 11) reason: there is an strange attribute hidden='1' which causes that in html5-ish browsers 2011/1/19 Major Péter majorpe...@sch.bme.hu I've clicked over my application and couldn't find any issue, so I'm (non-binding) +1. Regards, Peter 2011-01-18 19:16 keltezéssel, Igor Vaynberg írta: this is the second vote to release wicket 1.5-rc1. all vote-blocking issues previously reported have been fixed branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ maven repo: https://repository.apache.org/content/repositories/orgapachewicket-044/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC this vote ends Friday, January 21 at 10:00am GMT-8 please test the release and offer your vote cheers, -igor
[wicketstuff core] preparing for 1.5-RC1
Hello, When we split master from the core-1.4.x branch we kept all of the original and working in 1.4.x projects and then adjusted the master/pom.xml to remove any projects that wouldn't compile with 1.5. Now that wicket 1.5-RC1 will be released soon we should work on getting as many of the non working projects in master working. Even if most are missing from the 1.5-RC1 I can do accelerated point releases as more are added. For some projects it could be as simple as adding them into the pom.xml and then working through the 1.5 migration changes directly on the present code. But for some projects the version in the core-1.4.x branch has been updated since the core-1.4.x branch was created (the master branch code is out of date). I've found a way in git to use the subtree merge that will allow the core-1.4.x/project files to be merged onto the master/project files, see: https://github.com/wicketstuff/core/wiki/Helpful-Git-Commands (scroll down to the last section) Steps: 1. Fork the https://github.com/wicketstuff/core repository 2. Follow the steps on the wiki page to backport the changes from a specific module. 3. Commit the merge (updating the pom.xml's back to 1.5-SNAPSHOT) 4. Add in additional commits as required to make the project compatible with wicket 1.5-SNAPSHOT (i.e. make it build) 5. Create a pull request onto master to let us pull in your changes. For the test I did with jdk-1.5-parent/jasperreports-parent I just committed directly into wicketstuff/core repository but I think using the pull functionality of github would be more verbose. Regards, Mike
Re: [vote] retry: release wicket 1.5-rc1
+1 (non-binding)... Findings (I can also create jira issues for all of them, just let me know): 1) based on Migration Guide 1.5, TabbedPanel improvement: 'ITab.getPanel() now returns WebMarkupContainerWithAssociatedMarkup instead of Panel so it is now possible to create tabs using Fragments or Panels rather then just Panels.' WebMarkupContainerWithAssociatedMarkup does not exists anymore and ITab.getPanel() returns Panel again. so it is no longer possible to use Fragments directly. 2) maven and artifactid 'wicket' if I understood it correctly, wicket is a virtual package which combines wicket-core, wicket-util and wicket-request in one. using maven 2.2.1 and if a do a mvn dependency:tree I get the following output [INFO] +- org.apache.wicket:wicket:jar:1.5-RC1:compile [INFO] | +- org.apache.wicket:wicket-core:jar:1.5-RC1:compile [INFO] | +- org.apache.wicket:wicket-util:jar:1.5-RC1:compile [INFO] | \- org.apache.wicket:wicket-request:jar:1.5-RC1:compile so I have now everything twice! cheers, gab On 19/01/11 02:16, Igor Vaynberg wrote: this is the second vote to release wicket 1.5-rc1. all vote-blocking issues previously reported have been fixed branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ maven repo: https://repository.apache.org/content/repositories/orgapachewicket-044/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC this vote ends Friday, January 21 at 10:00am GMT-8 please test the release and offer your vote cheers, -igor !DSPAM:4d35d91166687663790136!
