there been already a community decision or were this only
deliberations?). According the tests I guess it heavily depends on what
actually is tested. Are this JXTG tests? Can they be moved into the
template block? Why do we care about maturity of template block if no
2.2 is planned at the moment?
Joerg
On 25.08.2005 13:51, Jorg Heymans wrote:
meantime here are some random trivia about my current and past person.
A warm welcome!
See (hopefully lots of) you in Amsterdam,
Jorg
oh and my name really is Jorg, so not Joerg or Jörg. This seems to bring
confusion sometimes, mostly for German
namespaces. You also
might have a look at the XML APIs in use. Maybe there is an older faulty
one from the Sun JVM?
Joerg
on
this project. Open for discussion of course.
I don't see we need another block, but that might evolve. For the moment
I think it's appropriate to put it besides the HTML stuff, starting (as
HTML) in the samples section maybe.
Joerg
On 22.08.2005 19:12, Ralph Goers wrote:
Is there a cost for the hackathon?
See the button of the registration page.
Joerg
be separate bundles instead of being packaged in the
Cocoon core bundle, also I didn't felt to write something more automatic
until we have finished changning build system to Maven2.
What about generating this file?
Joerg
On 12.04.2005 12:23, Jochen Kuhnle wrote:
So do I enter the context patch into bugzilla now?
What's the progress on this? Though I found the bug [1] I can not read
it, bugzilla has problems at the moment.
Joerg
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=34781
for Cocoon 2.1.x. If it is just an issue
for the library update we simply don't need to update each library to
each version.
Joerg
for working
mirror, mess with endorsed directories, install MySQL, rebuild kernel,
etc. I think it should stay that way.
+1 Me too.
Joerg
was so called core block. So you can most easily remove it
from your code base if you want to use another authentication framework.
But delivering a webapplication framework without an authentication
sub-framework is not imaginable ;-)
Joerg
much of a difference.
Of course it depends - as always. But you must not forget that XML is
not cached in its file version, but in a processed form: see the
org.apache.cocoon.components.sax package. So there might be advantages
for external caching too.
Joerg
had a bug about it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997. It got resolved
by setting it to duplicate - it seems to early. From what I see we
should reopen it and get it fixed.
Joerg
.
(These systems might work (and be maintainable) only because Cocoon
pipelines are based on clean and simple concepts ;-) )
Joerg
? /shrug
It's in the scratchpad.
That was what I meant. It's in the scratchpad for more than two years.
Joerg
is harder to write than XSLT. Many design decisions in Cocoon
were made to heighten the barrier of abuse.
Introducing a trax serializer means that what you see in the sitemap
serializer declaration is only *part* of what is output. There is a
huge difference between the two, and I can see why Joerg
.
No! Ok, if you need it, start a vote thread about adding TraxSerializer
to trunk/scratchpad. Otherwise just commit it.
Joerg
for not using xsl:output information, but
putting it into serializer component declaration. Shall they no longer
be valid?
Joerg
approaches (SourceWritingTransformer,
DOMSessionTransformer (both with side effects)) or widely unused (why is
the TraxGenerator still in trunk after more than 2 years?). Why shall we
add another component that's problematic (at least in my POV, see above)?
Joerg
transformer steps and the standard
serializer.
But the important thing is that using an XSLT internally is merely an
implementation detail. Exposing the XSLT implementation to users is
what Joerg and I take issue with. (Don't mean to speak for you here,
Joerg, correct me if I'm misquoting you
wondering if this thread was about virtual serialization. It's
not.
It is not, but if you break your stylesheet into multiple steps
(transformer(s) + standard serializer), you can put them together into a
virtual serializer.
Joerg
in both directions!
I'm tired of this discussion.
Me too.
Joerg
... The standard
tasks like getting rid of alien namespaces can be encapsulated. You
should not provide any access to the stylesheet. And then it should not
be called XSLSerializer, but something like
MoreSophisticatedXMLSerializer - however you will call it.
Joerg
On 07.08.2005 01:27, Jason Johnston wrote:
But the important thing is that using an XSLT internally is merely an
implementation detail. Exposing the XSLT implementation to users is
what Joerg and I take issue with. (Don't mean to speak for you here,
Joerg, correct me if I'm misquoting you
about an
I18nTransfomer after your stylesheet? Your approach also reduces the
reusability of the stylesheet as it is tied to a specific output format.
Joerg
On 04.08.2005 22:20, Joerg Heinicke wrote:
Compiling 268 source files to
/export/home/ray/cocoon-2.1/build/cocoon-2.2.0-dev/blocks/forms/dest
/export/home/ray/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/event/ProcessingPhase.java:22:
as of release 1.5, 'enum' is a keyword, and may
be accepted explicitely. I like this much more than the paper
work. Is it possible to customize Bugzilla for Apache in that way?
Joerg
pleased to propose Jorg Heymans, as a committer.
Please cast your votes:
Definitely +1
Joerg
again (it was on http://www.xulplanet.com).
Do you mean something like this demo:
http://www.faser.net/mab/chrome/content/mab.xul
More info here: http://www.faser.net/mab/
Yeah, this looks like a perfect example. It gives a real Rich Client
feeling.
Joerg
/refdoc/**) commit
=== must be once again xului of course =^^^
privileges to our SVN code repository.
+1
Joerg
HTML. XUL has
its own templating mechanism.
Joerg
posted two links in one of these mails. If not I can search for
them again (it was on http://www.xulplanet.com).
Joerg
On 25.07.2005 14:48, Carsten Ziegeler wrote:
Our policy asks to just have the latest release on the dist server - all
old releases are in the archives and still available.
If noone objects I will remove the 2.0.4 from the dist server, leaving
just 2.1.7 there. Now that we have eight release in
(AbstractComponentHandler.java:74)
... 20 more
Test org.apache.cocoon.jcr.source.JCRSourceTestCase FAILED
==
Hmm, could it be that our build system is not really reliable?
Joerg
On 24.07.2005 22:08, Ralph Goers wrote:
My understanding is that gump only builds the latest version. That
would be trunk.
This should not prevent us from building 2.1 branch as it would control
also our dependencies between the blocks.
Joerg
difference. I thought pointing with svn:external to the blocks dir would
avoid the duplication.
I think we should really start seeing branch as what it should be: a
maintenance branch ;) And try to get a 2.2 out asap.
Nothing agains it :-)
Joerg
the above into account?
Joerg
block in the branch. Why? And why are the blocks in the
branch not handled in the same way (svn:external) as in trunk? Couldn't
this be done transparent to the users? And while we are at it: From what
I see the branch is not built by gump. Any reason for this?
Joerg
.
+1
Joerg
is read is independent on the generator
itself, but only depends on the source provided via @src in sitemap. Having this
in mind ResourceGenerator is not the best name possible IMO and will continue
the irritating naming.
Joerg
so many
delegating methods.
And why do you want to leave DG untouched at all? Couldn't TG do the same?
Regarding 3.: +1 for doing it the same way - what ever we will decide.
Joerg
by
starting with the unclean way (DirectoryG extends TraversableG with old
namespace and directory/file metaphore as you wrote it), deprecating it
at the same time and making the TraversableG the officially supported one?
Joerg
while xsl:include
does not. I am unable to verify that right now though.
This would break my analogy from the comment/explanation mentioned
above, but if the XSLT spec is that stupid and if it would help to solve
the issue, I can live with it too :-)
Joerg
to:
$COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java
Joerg
On 10.07.2005 13:23, Reinhard Poetz wrote:
In order to make his life and the life of his two mentors (Sylvain and
I) easier, I want to give him *temporary* and *restricted*
(http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/**) commit
privileges to our SVN code repository.
+1
Joerg
vanish as soon as possible. Blocks
are either supported *by the community* or not.
The page still exists ;-)
Joerg
On 07.07.2005 17:32, Carsten Ziegeler wrote:
Ok, I could cast it to ValidationErrorAware but it
seems a little bit strange to have a validate() method on the widget but
no isValid() method.
+1 makes sense.
Joerg
no objections for fixing side effects.
Joerg
just need to check out the
appropriate branch.
They only get access to a directory per GSOC project in the whiteboard.
Joerg
the update method in XMLResourceBundle has a sourceURL
parameter at all. It makes no sense to change the source URL of a bundle
when reloading it, does it? Wouldn't it be better to save the sourceURL
as field of the XMLResourceBundle and remove the parameter from the
update method?
Joerg
--
We definitely agree, that this would be a powerful construct. Another way
could be, to pass the relevant wurfl-capabilities to the xsl as parameters
and let itsself decide, what to do with it.
Thanks for any help!
Joerg Rasinger
--
ECCA - eTourism
though.
Can this be determined?
Yep. If (the selection-list widget has not a repeater as ancestor) OR
((the selection list widget if has a repeater as ancestor) AND (the
repeater has less than 2 rows)
No, see above (repeater is not sufficient). :-)
Joerg
I had
in mind with form.) Time based caching can be easily done on the pipeline as
we know or using the cached: pseudo protocol, but then you still either have no
buffered selection list sax events or you need an object holding the buffer with
the necessary lifetime.
Joerg
to be changed then in
org.apache.cocoon.forms.datatype.DynamicSelectionList.generateSaxFragment(ContentHandler,
Locale, Source).
Joerg
.
Joerg
function-available('xalan:checkEnvironment') would be the best one I
think.
Joerg
[1]
http://cvs.sourceforge.net/viewcvs.py/docbook/xsl/fo/callout.xsl?rev=1.12view=markup
(line 25)
[2]
http://cvs.sourceforge.net/viewcvs.py/docbook/xsl/html/callout.xsl?rev=1.11view=markup
(line 36)
[3]
http
On 28.05.2005 03:20, Antonio Gallardo wrote:
Hi Joerg:
I am glad to see you active on the list again. As I told you in GT2004, I
like your radar over my work. :-)
Hi Antonio,
yeah, I'm back again at least for a few days (starting last weekend,
ending tomorrow). I hope to get my internet
something to be avoided as far as
possible IMO. Would it not be possible to have just one buffering
SelectionListHandler per source and request (or form) with an internal
SAXBuffer?
Joerg
have source validities? Wouldn't help a
SelecionListHandler storing the SAX events in a SAX buffer and
resaxifying the events if source validity is still valid and wouldn't it
fulfill all requirements?
Joerg
at
setSelectionList(SelectionList):
* @param selectionList the selection list or codenull/code to have
no selection list.
Joerg
in the template.
Joerg
it possible to handle a wrong interpreter like a not
matching matcher and resume searching for another handler of the
continuation? We also don't throw an exception when the first matcher
does not match ...
Joerg
to an internet connection finally my +1.
Joerg
).
Thanks for fixing all the bugs I introduced by my fast commit without
thinking :-( Sorry for any inconveniences.
Joerg
On 13.05.2005 11:37, Nathaniel Alfred wrote:
I think synchronized(session) should never be used as vehicle to
coordinate concurrent requests because there is no convincing guarantee
that it is always working as expected.
Joerg, if you want to do it in your usercode, I don't mind
for the current server session. Only the
access to the map itself must be blocked for all requests.
Joerg
? It is not synched on the local variable
but on the object that is referenced by the local variable.
Joerg
may totally avoid it except once.
http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double_p.html
Joerg
() methods? Of
course we could forward getSession() to a factory method in HttpSession that
decides whether to create a new wrapper or return the existing one.
I have an implementation with map in HttpRequest and without double-checked
locking idiom. Shall I commit it?
Joerg
, really? It's at least 4 years old!
Do you want to do such a step in a maintenance release?
Joerg
with the different types of references
- and though I read it before implementing I did not take care about exactly
that case. Now it's fixed (and I hope I did not add a typo or so as I have no
Java-understanding editor on this PC).
Joerg
)
xsp:
org.apache.cocoon.components.xscript.XScriptManagerImpl (1 match)
org.apache.cocoon.components.language.markup.xsp.XSPUtil (1 match)
Joerg
of
HttpSessionBindingEvent, just the information that the wrapper was removed - and
this must happen when the session is invalidated.
WDYT?
Joerg
[1] http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/
HttpSessionAttributeListener.html
#attributeReplaced
introduce a memory leak. But maybe WeakHashMap would take care
of this...
Yes, see Sylvain's proposal or my other mail.
Joerg
[1] http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/
HttpSession.html
? The alternative would be a synchronized
static factory method in the class, but how can I get the Avalon lifecycle then?
Joerg
Sylvain Wallez sylvain at apache.org writes:
Joerg Heinicke wrote:
Hello,
I have a question regarding synchronization in flow script. I need an object
per session, so the instantiation must be synchronized. Furthermore the
object
is an Avalon component, so I need to call something
on every request a new wrapper is instantiated which is really
bad. It is not possible to synchronize on Cocoon session objects. What we
probably need is a Map mapping the server sessions to the wrapper objects.
WDYT?
Joerg
[1] http://svn.apache.org/viewcvs.cgi/cocoon/tags/RELEASE_2_1_7/src/java/org
Torsten Curdt tcurdt at apache.org writes:
Any Cocooners based in Stuttgart?
I'm near Stuttgart (Reutlingen to be exact) since the beginning of this year.
But I guess I can not help much as I have not been in Stuttgart except at the
station in these 4 months.
Joerg
things :-) and will just redirect you to the documentation (the
infamous RTFM). It should be easier to raise some discussion on this discussion
on the users list though.
Joerg
. And from my searches
[1] and comparisons with existing Cocoon code [2] I got the feeling it must be
possible without selectors. Is it? And how must the thing be set up (roles
file + xconf)?
Thanks in advance,
Joerg
[1] http://excalibur.apache.org/framework/guide-cop-in-avalon.html
not, does now and works now)! Sometimes it is so easy. Thank
you very much.
Joerg
user friendly, but IMO it is
much more user friendly than the other tools. In contrary to JIRA in bugzilla I
find what I'm searching for ...
Joerg
release section with the placeholders. Add a dummy action
here.
...
What do you think? IMO this should fix the web site when building the
documentation from released sources.
Joerg
On 27.03.2005 14:33, Joerg Heinicke wrote:
Hi all,
I have been rarely on the lists in the last weeks. I even had to read
the changes file to know what's going on with Cocoon. :-)
But when reading the History of Changes [1] I saw the string Version
@version@ (@date@) instead of the release's
it with the core, but
storing it in an extra block, so anybody can remove it when needed, is the best
I can imagine. We still can brand Cocoon as web application framework.
Joerg
On 30.01.2005 05:37, Stefano Mazzocchi wrote:
For this reason, I propose that we discontinue the distribution of
Linotype inside cocoon as a block, by deprecating it in the next 2.1.x
release and by removing it alltogether in 2.2
+1
Joerg
=cocoon/trunk/gump.xmlr2=149029
depend project=cocoon-block-authentication-fw/
-depend project=cocoon-block-html/
+depend project=cocoon-block-form/
depend project=cocoon-block-cron/
form*s*?
Joerg
On 24.01.2005 07:47, Reinhard Poetz wrote:
Anyway, as we agreed that 2.2 should come soon, I don't think it's worth
doing the refactoring.
+1
Joerg
/
/map:transform
map:serialize /
/map:match
Any further idea?
Joerg
a list of locations. Therefore the current behaviour and the
workaround should not only be well-documented, but also changed.
Joerg
. The first directory in the String[] is evaluated and taken from cache
- with all the other bundles attached as parents.
Joerg
included.
But providing the without-dependencies-version additionally, not
substitutingly, dispels my fears.
Joerg
the catalogue and its
location, later accesses to the transformer will not have the correct catalogues
available. Is it possible to either prevent the caching of the catalogues at all
or - even better - to influence the caching by adding the dependency on the
request attribute?
Thanks,
Joerg
Joerg Heinicke joerg.heinicke at gmx.de writes:
I have a problem with
the caching of the i18n catalogues. The location of one i18n catalogue is
defined to be dependent on {request-attr:xyz}, so it can change on each
request. But the first access to this i18n transformer caches the catalogue
On 08.01.2005 23:20, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Sat Jan 8 14:20:56 2005
New Revision: 124685
URL: http://svn.apache.org/viewcvs?view=revrev=124685
Log:
inner classes - nested classes
What's the reason for, the advantage of this change?
Joerg
by intent? Especially org.apache.ojb.log.
Joerg
the protocol cocoon:/ to retrieve the JSP result causes an
ClassCastException. Calling test.jsp directly (without JXTemplate) works
well.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32128
Joerg
) {
+return status;
}
}
}
What about releasing the Source's??
Joerg
it.
Joerg
);
this.binding = null;
} catch (Exception e) {
throw new CascadingRuntimeException(Could not create form
instance, e);
}
}
Joerg
.
I wish you all a happy new year!
Joerg
601 - 700 of 1679 matches
Mail list logo
