Il giorno 02/nov/05, alle ore 23:06, Stefano Mazzocchi ha scritto:
+1 to new skin but only with new content.
Agree.
-1 to the logo, no reason to change a widely recognized one with a
new one just for sake of change.
Agree as well. Let's keep the current logo, at least until we release
Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
-0.5. Too many CForms last minute changes, as you wrote in response
to Sylvain.
Incidentally, I'm +1 on Sylvain's proposed changes to element id
On 11/3/05, Jeroen Reijn [EMAIL PROTECTED] wrote:
Helma,We have the same problem with our sites. As far is I know they only workaroundis by putting a space between the script tags like script#160;/script
Thanks. I already did that, but it's really not that elegant. BTW I
somehow managed to get
Carsten Ziegeler wrote:
Ralph Goers wrote:
And what about the case that I added support for - full screen with all
the navigation still present?
Actually, your changes broke the full screen feature if no tab is
available. If you look at the current portal demo, full screen does not
Ugo Cei wrote:
Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
-0.5. Too many CForms last minute changes, as you wrote in response to
Sylvain.
+1 from me. Let's not delay once more the baby
The last
Sylvain Wallez wrote:
Ugo Cei wrote:
Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
-0.5. Too many CForms last minute changes, as you wrote in response to
Sylvain.
+1 from me. Let's not delay
Upayavira wrote:
Incidentally, I'm +1 on Sylvain's proposed changes to element id
generation strategy.
My question before voting is how have you gone about identifying that a
colon is a valid character within ids in all browsers?
I checked the XML specification:
hepabolu wrote:
Stefano Mazzocchi wrote:
+1 to new skin but only with new content.
I'd like a more lighter (i.e. in color) skin, much along the lines of
the current Maven site.
If you want to make new content a prerequisite for a new skin, it won't
happen for a long time. The speed
(I think this should be discussed in a separate thread)
Sylvain Wallez wrote:
The last minute change is just about replacing -input with :input
within two XSLs, to avoid problems later.
Isn't : used as separator for the namespace prefix?
I don't know if this applies to IDs too, but perhaps
Andreas Hochsteger wrote:
(I think this should be discussed in a separate thread)
Sylvain Wallez wrote:
The last minute change is just about replacing -input with :input
within two XSLs, to avoid problems later.
Isn't : used as separator for the namespace prefix?
I don't know if this
[ http://issues.apache.org/jira/browse/COCOON-1672?page=all ]
Sylvain Wallez closed COCOON-1672:
--
Resolution: Fixed
Fixed by revisions r330513 and r330514
Help popup broken in CForms samples
---
Key:
Sylvain Wallez wrote:
This usage in CForms has already been introduced by the recent library
stuff, which associates prefixes to libraries, thus effectively
forbidding the use of : in widget ids (otherwise you cannot
differenciate between a widget name and a composite name that references
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36810.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Upayavira wrote:
hepabolu wrote:
Stefano Mazzocchi wrote:
+1 to new skin but only with new content.
I'd like a more lighter (i.e. in color) skin, much along the lines of
the current Maven site.
If you want to make new content a prerequisite for a new skin, it won't
happen for
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This usage in CForms has already been introduced by the recent library
stuff, which associates prefixes to libraries, thus effectively
forbidding the use of : in widget ids (otherwise you cannot
differenciate between a widget name and a
[ http://issues.apache.org/jira/browse/COCOON-1594?page=all ]
Jeremy Quinn closed COCOON-1594:
Resolution: Fixed
updated SQLTransformer and TextRecorder to not strip spaces from the SQL Query
SQLTransformer swallowing whitespace on
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This usage in CForms has already been introduced by the recent
library stuff, which associates prefixes to libraries, thus
effectively forbidding the use of : in widget ids (otherwise you
cannot differenciate between a
On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
(if we vote to not release on friday, I can do the release on any
day in
the next week).
What about these three issues targeted for 2.1.8 ???
Ralph Goers wrote:
Ouch. Well I could look into fixing that tomorrow. It needs to work in
2.1 and I presume the changes below are only going in trunk.
Yes, all new features are just going to trunk.
Well, JSR-168 (almost) defines NORMAL, MAXIMIZED and MINIMIZED.
Unfortunately, both
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 57
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 57
2005/11/3, Pier Fumagalli [EMAIL PROTECTED]:
On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
(if we vote to not release on friday, I can do the release on any
day in
the next week).
What about these three issues
Hi all,
I've just committed an example of how our repository could be structured
to support the ongoing componentization, new (osgi) block structure and
M10N. Daniel suggested this flat structure a while ago [0], maven [1]
and eclipse [2] use a similar layout.
The example is in the whiteboard,
A standard block layout can look like this :
/cocoon-forms-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
-- pom.xml
Is a multimodule pom containing
modules
moduleapi/module
moduleimpl/module
modulesamples/module
Jorg Heymans wrote:
The concept is the following :
/trunk
pom.xml
/cocoon-core
/cocoon-forms-block
/cocoon-ajax-block
/cocoon-asciiart-block
...
Please have a look and tell me what you think.
IIRC, we already have separated out blocks out of the core, into
Upayavira wrote:
Daniel Fagerstrom wrote:
...
Anyway, for the time beeing I think it is better to focus on making it
as easy as possible to use SQL from flowscripts and present the result
sets in CTemplate. Then if we don't get it easy enough we can start to
think about doing part of ESQL
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Now, I find it rather strange to keep the SQLTransformer and ESQL
because some people find them being the best way to do simple
reporting at the same time as the community strongly oppose building
a modern replacement of them in CTemplate,
Vadim Gritsenko wrote:
IIRC, we already have separated out blocks out of the core, into
svn:/cocoon/blocks/
separating meaning to move them to a separate directory ? The flat
layout doesn't mean they aren't separated.
Where each block is treated as independent project, and has own
Jorg Heymans wrote:
Hi all,
I've just committed an example of how our repository could be structured
to support the ongoing componentization, new (osgi) block structure and
M10N. Daniel suggested this flat structure a while ago [0], maven [1]
and eclipse [2] use a similar layout.
The example
Jorg Heymans wrote:
A standard block layout can look like this :
/cocoon-forms-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
-- pom.xml
Is a multimodule pom containing
modules
moduleapi/module
moduleimpl/module
modulesamples/module
Jorg Heymans wrote:
Vadim Gritsenko wrote:
IIRC, we already have separated out blocks out of the core, into
svn:/cocoon/blocks/
separating meaning to move them to a separate directory ? The flat
layout doesn't mean they aren't separated.
Separating meaning they are separate projects with
Vadim Gritsenko wrote:
Jorg Heymans wrote:
The concept is the following :
/trunk
pom.xml
/cocoon-core
/cocoon-forms-block
/cocoon-ajax-block
/cocoon-asciiart-block
...
Please have a look and tell me what you think.
IIRC, we already have separated out blocks out of
Hello,
FYI we had to update jtidy in our project to see an HTML parsing bug fixed.
We used this: http://jtidy.sourceforge.net/nightly/jtidy-r8-SNAPSHOT.zip
This version was last updated in september 2004.
Best regards,
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel :
jx macros output extra whitespace
-
Key: COCOON-1677
URL: http://issues.apache.org/jira/browse/COCOON-1677
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8-dev (Current SVN)
Reporter: Jean-Baptiste
[
http://issues.apache.org/jira/browse/COCOON-1677?page=comments#action_12356714
]
Mark Lundquist commented on COCOON-1677:
cf. Issue 1381 (http://issues.apache.org/jira/browse/COCOON-1381)... this is
probably the same thing.
BTW, how do you
[
http://issues.apache.org/jira/browse/COCOON-1629?page=comments#action_12356713
]
Jean-Baptiste Quenot commented on COCOON-1629:
--
No, initial-value attribute does not work, neither as child
element.
No default value in forms binding
[ http://issues.apache.org/jira/browse/COCOON-1677?page=all ]
Jean-Baptiste Quenot closed COCOON-1677:
Resolution: Duplicate
Same as COCOON-1381
jx macros output extra whitespace
-
Key:
Daniel Fagerstrom wrote:
Jorg Heymans wrote:
A standard block layout can look like this :
/cocoon-forms-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
-- pom.xml
Is a multimodule pom containing
modules
moduleapi/module
Daniel Fagerstrom wrote:
The current structure with trunk/tags/branches under each block will
become rather unconvenient as soon as we start to relase and tag things.
Right now you can just check out svn:/cocoon/blocks without any
problems, but with a number of tags for each blocks you soon
Hi,
I have an existing Cocoon 2.1.7-based project in which I would like to
upgrade Commons Lang to 2.1, and I'd like to make sure that won't cause
any problems for Cocoon. Were any source changes required for Commons
Lang 2.1 in BRANCH_2_1_X?
Thanks,
Mark
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 57
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 57
Mark Lundquist wrote:
Hi,
I have an existing Cocoon 2.1.7-based project in which I would like to
upgrade Commons Lang to 2.1, and I'd like to make sure that won't
cause any problems for Cocoon. Were any source changes required for
Commons Lang 2.1 in BRANCH_2_1_X?
The safest way to know
On 03.11.2005 06:47, Carsten Ziegeler wrote:
Please cast your votes for releasing 2.1.8 on friday, 4th of November.
+0
Too much to do at the moment to test Cocoon. I'm just reading the lists
at the moment. And from those I don't have the best feelings about the
latest changes.
Jörg
Vadim Gritsenko wrote:
Separating meaning they are separate projects with independent release
cycles, as in:
Where each block is treated as independent project, and has own
tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
start having own tags.
Perfect, my proposed
Daniel Fagerstrom wrote:
-- /cocoon-forms-block, /cocoon-asciiart-block ...
All modules that we choose to host and support ourselves land in the
repository root.
Does the block suffix buy us anything? Everything, core included will be
a block.
if anything the suffix could be something
Daniel Fagerstrom wrote:
Would prefer puting API dependencies in the API module and let the
impl depend on the api and the samples on the impl. Doesn't the
tranistive dependencies work well enough or what is the reasons for
having dependencies at parent level?
Well i figured it would buy us
Jorg Heymans wrote:
Andreas Hochsteger wrote:
If you take everything into account, both API and implementation can
have their own dependencies, e.g.:
* B (API) depends on A (API)
wow, multiple APIs in one block ?
Actually I meant A through D to be blocks, where the blocks A and B just
Sylvain Wallez wrote:
Upayavira wrote:
Incidentally, I'm +1 on Sylvain's proposed changes to element id
generation strategy.
My question before voting is how have you gone about identifying that a
colon is a valid character within ids in all browsers?
I checked the XML
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This usage in CForms has already been introduced by the recent
library stuff, which associates prefixes to libraries, thus
effectively forbidding the use of : in widget ids (otherwise you
cannot differenciate between a
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
IIRC, we already have separated out blocks out of the core, into
svn:/cocoon/blocks/
Where each block is treated as independent project, and has own
tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
start having own
Jorg Heymans wrote:
Vadim Gritsenko wrote:
Where each block is treated as independent project, and has own
tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
start having own tags.
Perfect, my proposed layout covers this use case. Each block will have
its own release
Hi,
as I'm currently staying in Shanghai, I was wondering if
there are any Cocooners here who are interested in meeting up
somewhere? So if you're interested in talking about Cocoon,
Open Source and related topics just drop me a line :-)
--
* best regards
* Jens Maukisch
Jorg Heymans wrote:
What if there is no real need for an api block? Do we still add it and
define for example the cocoon-core dependency there or do we leave it
out alltogether ?
I would lead it out altogether. Leaving it in kind of implies that
there should be an api and will probably
On 04.11.2005 02:09, Antonio Gallardo wrote:
Yep. The . and / are already checked in
AbstractWidgetDefinition.setCommonProperties(). We just need to add :.
Why we need to use a symbol at any cost ? Can we use a simple word
prefix? As cform-[widgetID]?
If you prefix the widget id with a
Joerg Heinicke wrote:
On 04.11.2005 02:09, Antonio Gallardo wrote:
Yep. The . and / are already checked in
AbstractWidgetDefinition.setCommonProperties(). We just need to add
:.
Why we need to use a symbol at any cost ? Can we use a simple word
prefix? As cform-[widgetID]?
If you
To be honest I'm not really happy about this vote: I counted only four
votes! I'm still trying to figure out what this result means to us?
Anyway, I counted two +1's, one +0.5, one -0.5 and some reservations for
releasing today.
My decision is to not release today, sorry, but imho there are not
On 04.11.2005, at 08:30, Carsten Ziegeler wrote:
To be honest I'm not really happy about this vote: I counted only four
votes! I'm still trying to figure out what this result means to us?
I suspect it means I haven't tested enough to be confident so
I don't know. Have all reported issues
58 matches
Mail list logo
