just noticed the below
this is a bad joke right?
markup: 1line
license: 14 lines
are we stripping the license block somewhere? or are we sending it to the
client?
you include two ajax editable choices and you get two of these headers in
the returned markup?
-igor
Modified:
Hmm Will you get it returned? It's a panel so it's only the content of it
that gets returned, right?
Frank
On 11/13/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
just noticed the below
this is a bad joke right?
markup: 1line
license: 14 lines
are we stripping the license block somewhere? or
But you are right though that we still have that issue with were and if we
strip headers. All pages .html (not extended), .css and .js files *will*
have the license header and until we come to an agreement between us and ASF
they stay. And that sucks IMO
Frank
On 11/13/06, Igor Vaynberg [EMAIL
So this way?
/ == home page
/?p=a == homepage with page params.
/?interface:xxx == an callback to an existing page
/?bookmarkablePage=xxx == an none mounted bookmarkable page request
/input == mounted bookmarkable page
and then
/a == this is not mounted like input above.. Then it should
And it increases memory usage. We might not transfer it to the client
but we cache the markup.
Juergen
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
But you are right though that we still have that issue with were and if we
strip headers. All pages .html (not extended), .css and .js files
Yeah similar to that. I mean we currently even cant employ file-endings.
e.g: you can have /page/param/param
but not /page/param/param.html wich would be even more nice and logic (IMHO)
imagine a mount where you could specify / as begin and .htm as end. -
you could have 1 handling-class for all
On 11/13/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
And it increases memory usage. We might not transfer it to the client
but we cache the markup.
Yes thats right. That sounds like stripping license headers (or replacing
with small one-line notices) at build time is the right solution.
Now that we have a decent infrastructure, we can use JIRA for
generating our changes report. This does mean that we need to do
everything through JIRA: additions, backports, etc.
Any ideas?
Martijn
--
a href=http://www.thebeststuffintheworld.com/vote_for/wicket;Vote/a
for a
I think that is too cumbersome. I'd prefer a really simple solution.
Either a one (1) line license header or nothing at all. Based on what
I understood from the mailing discussing there doesn't seem to be a
clear understanding within Apache if Wicket markup is required to have
the license header
Hi,
I converted the form input example this weekend so that it uses one
page and a properties (or xml) file per supported locale. One problem
I have to fix is the fact that Persian (fa IR) is a 'left-to-right'
language (see http://www.i18nguy.com/markup/right-to-left.html).
Now, it kind of
what about them do you find unreadable?
i would be +1 for this. keeping up changes.xml is a pain imho, and since a
good amount will already be entered into jira it will take work off us.
-igor
On 11/13/06, Erik van Oosten [EMAIL PROTECTED] wrote:
My 2ct:
JBoss does this. I find their change
This would be the minimal thing to make a RTL language look ok.
Japanese for instance is a LTR language (like English and German are).
Eelco
On 11/13/06, Juergen Donnerstag [EMAIL PROTECTED] wrote:
I'm not sure. Isn't it that the whole form / page layout require
changes to make it look right.
you can have .html just fine.
Only you want to have xxx/param.html?
so like:
/product/110203.html?
or
/product/id/110203.html?
Why that html there?
What does that bring?
I don't find it nicer that is just taste.
And i guess you could build it just fine. Just make another url encoder.
And
What I don't like is that is a plain list without any notion on what is
important and what is not. Of course, its ok to maintain the changes in
a tracking system. But presenting the list of changes exactly as they
come from Jira is pretty hard on the reader. It should be fun to read
change
On 11/13/06, Erik van Oosten [EMAIL PROTECTED] wrote:
What the heck, I'll
volunteer to write those release notes if someone gives me that jira list.
https://issues.apache.org/jira/browse/WICKET?report=com.atlassian.jira.plugin.system.project:changelog-panel
:)
-igor
Erik.
Igor
Hi Johan,
yes i know its not component, and its evil :O
the *.html would mean a unique identifier where a filter could be attached
to and so static resources wouldnt be touched.
The one class - well, i know its a hard discussion, but as we also have
wicket-apps where whole app is just 1 page
I'm not *that* familiar with wicket-examples so I would like to hear about
if anyone knows if there are any legal issues in it know and if all the
source code in it is ASL (compliant). In particular I'm thinking about these
folders:
src/test/java/com/meterware/httpunit (doesn't seem to be used,
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
src/test/java/com/meterware/httpunit (doesn't seem to be used, no license
header at all)
This was a fix for XML and/or JavaScript not being parsed correctly, iirc.
The httpunit license is MIT or BSD type:
i dont think this is a very common usecase, at least it has never been
requested before. so what i am tempted to tell you is to implement your own
IRequestCodingStrategy to handle this. and if you would like you can provide
it as a patch and we might put it into extensions or core.
-igor
On
To cut down on our API and remove some ultra-convenience stuff, I
propose to remove RequiredTextField from our API. Requiredness is
easily achieved using 'setRequired(true)', and therefore removes the
need for a special field.
[ ] yes remove RequiredTextField in 2.0 and 1.3
[ ] yes remove
[x] yes remove RequiredTextField in 2.0 only
-igor
What about a file like this:
http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-examples/src/test/java/nl/openedge/util/jetty/JettyMonitorException.java?view=co
Case of a stupid slip. I'll testify that in front of a jury :)
Eelco
On 11/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
What about a file like this:
http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-examples/src/test/java/nl/openedge/util/jetty/JettyMonitorException.java?view=co
Case of a stupid slip. I'll testify that in front of a jury :)
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
But anyway are you willing/have enough rights to change the license to ASL?
Else I will add them to NOTICE.txt
He's the original author, regardless of the quality :-).
Move the code to the wicket namespace, and change to ASL. Or let Eelco
do
On 11/13/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
Before we start a vote for renaming our package structure, I think we
should carefully consider the consequences.
The proposal is to rename our wicket.* package to org.apache.wicket.*
There is no requirement within Apache to do so, but it
yeah, what eelco said.
-igor
I'm all for only changes the packages for 2.0. I still would like to
keep the breaks for 1.3 minimal, and generally get it over with asap.
Doing it just before the first public release sounds fine to me.
Eelco
yeah +1 to that
On 11/13/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
yeah, what eelco said.
-igor
I'm all for only changes the packages for 2.0. I still would like to
keep the breaks for 1.3 minimal, and generally get it over with asap.
Doing it just before the first public release
I guess this should work ok, so this way pages written previously wont be
harmed, and we have support for programmatically setting the direction.
Eelco, wouldn't you consider adding the method to Component instead of
WebPage ?
On 11/13/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
This would be
+1
Juergen
On 11/13/06, Frank Bille [EMAIL PROTECTED] wrote:
yeah +1 to that
On 11/13/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
yeah, what eelco said.
-igor
I'm all for only changes the packages for 2.0. I still would like to
keep the breaks for 1.3 minimal, and generally get it
Ok, let me know when its needed.
Erik.
Igor Vaynberg schreef:
On 11/13/06, Erik van Oosten [EMAIL PROTECTED] wrote:
What the heck, I'll
volunteer to write those release notes if someone gives me that jira
list.
Yeah thats it. Numbers are LTR text is RTL.
On 11/14/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/14/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
I guess this should work ok, so this way pages written previously wont
be
harmed, and we have support for programmatically setting the
31 matches
Mail list logo
