de sun's views and java speed on the
client will *finally* emerge from the casted shadows.
--
Stefano.
on 6/27/03 11:48 AM Stefano Mazzocchi wrote:
> As for implementing this, I planned to look into this today.
Ok, I dived into the code and I found where the problem is. The call to
the sitemap invocation is located in the class
org.apache.cocoon.components.flow.AbstractInterpreter
stefano 2003/06/27 14:08:39
Removed: src/java/org/apache/cocoon/components/flow TODO
Log:
removed because somewhat obsoleted by the FOM discussion
stefano 2003/06/27 13:41:48
Modified:..cvsignore
Log:
adding .DS_Store found in MacOSX folders
Revision ChangesPath
1.2 +2 -0 cocoon-2.1/.cvsignore
Index: .cvsignore
===
RCS file
stefano 2003/06/27 13:10:43
Modified:src/scratchpad/webapp/samples scratchpad-samples.xml
src/webapp/samples samples.xml
Added: src/webapp/samples/paginator/content list.xml text.xml
src/webapp/samples/paginator/stylesheets list2html.xsl
stefano 2003/06/27 13:08:38
cocoon-2.1/src/webapp/samples/paginator/stylesheets - New directory
stefano 2003/06/27 13:08:38
cocoon-2.1/src/webapp/samples/paginator/pagesheets - New directory
stefano 2003/06/27 13:08:38
cocoon-2.1/src/webapp/samples/paginator/content - New directory
stefano 2003/06/27 13:08:37
cocoon-2.1/src/java/org/apache/cocoon/transformation/pagination - New directory
stefano 2003/06/27 13:08:38
cocoon-2.1/src/webapp/samples/paginator - New directory
stefano 2003/06/27 13:08:38
cocoon-2.1/src/webapp/samples/imagereader - New directory
therwise the error page is just returned as a standard page).
>
> Is it reasonable enough to add error codes (404 and 500) to the errors> block in the built webapp's sitemap? Seems kinda obvious thing to do to
> me.
+1
--
Stefano.
suggestion: use the higher component manager but
just check if the returned component implements SitemapModelComponent
and if so return null or raise an exception.
Slower to reject calls for invalid components, but takes
into consideration.
What do you think?
--
Stefano.
ecause there
could be services that are publicly available and then wrapped by the flow.
For future "real block" this might well be a common scenario.
As for redirect(), redirecting to an internal-only pipeline will
obviously fail already, we don't have to enforce that.
As for implementing this, I planned to look into this today.
--
Stefano.
e,
> http://www.parrotcode.org/ is not. :-)
>
Wow, a VM with native continuations, very interesting.
Question: do you think it would be possible to compile java source code
into parrot bytecode? how would the limited Perl typing capabilities
would impact that?
I feel like crosspollinating these days ;-)
--
Stefano.
stefano 2003/06/26 12:44:05
Modified:src/scratchpad/src/org/apache/cocoon/components/flow/javascript/fom
FOM_Cocoon.java
Log:
commented out the hooks to the FOM event model that we'll design and implement in
the future
Revision ChangesPath
on 6/26/03 2:13 PM Reinhard Pötz wrote:
>
>>-Original Message-
>>From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, June 26, 2003 12:22 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: FOM implementation
>>
>>
>>"
ompiled at all, and I've heard it argued
> that interpreted languages will be used exclusively in the future with
> very large code bases for that very reason.
hmmm, compilation is a highly parallelizable task so I don't really buy
this as a valid argument against compiled languages.
--
Stefano.
he given role and check if it doesn't
implement "SitemapModelComponent", in which case an exception should be
thrown.
What do you think?
--
Stefano.
he given role and check if it doesn't
implement "SitemapModelComponent", in which case an exception should be
thrown.
What do you think?
--
Stefano.
stefano 2003/06/25 20:09:49
Modified:src/blocks/linotype/samples/stylesheets news2rss-0.91.xslt
news2rss-2.0.xslt
Log:
fixing problem with RSS validation, strangely enough, the RSS validator doesn't
appear to validate the resulting RSS anymore becau
> +1
+1
>
>>
>>
>>PS: This makes me think that Linotype should have its own project rather
>>than being just a block...
>>
>
> I think some other current blocks are good candidates as subprojects but
> I guess we are not ready for that now - I think, this fits a little bit
> in the context of "real blocks".
I agree with Carsten here, until we have a real deployment
infrastructure, it would just create more harm than good to
hyperfragment our blocks into their own projects.
--
Stefano.
hard CVS datamining
problem. Anyway, agora can visualize any structure you come out with so
if you want to experiment with it, it would be very cool and I might
even be able to help you.
> But the latter part is not really proper statistics. Let me try to back
> that up when I have some time.
Cool, let me know when you come up with some data to show.
--
Stefano.
on 6/25/03 4:55 PM Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>
>>I think that the option of "active and direct" collaboration between
>>Cocoon and Rhino would be better for both. It might increase their
>>community, create a solid political link
plate caching is hard to estimate.
> Giving access to "Request" to the template at all times, implies that we
> cannot really make sure whether the generator will (or will not) produce the
> same output over and over again...
>
> I'd say to make it optional, or to have a way to "map" the objects going
> into the JXPath context of the GarbageGenerator...
this is probably a more transparent way of doing it, but again I'm not
sure how expensive this is going to be.
What do you think?
--
Stefano.
Maybe we should disable input module substituion
> within
> call elements of the sitemap. (I don't know if this is possible at all.)
>
> What do you think?
-1, it's too harsh and people would not understand why we are doing this.
i simply expect people to stop asking for URI fragments to the request
to assemble the URI calls by themselves and let the link translation
transformers do it for them.
But again, we have to show what we consider a best practice so that
people can follow.
--
Stefano.
Maybe we should disable input module substituion
> within
> call elements of the sitemap. (I don't know if this is possible at all.)
>
> What do you think?
-1, it's too harsh and people would not understand why we are doing this.
i simply expect people to stop asking for URI fragments to the request
to assemble the URI calls by themselves and let the link translation
transformers do it for them.
But again, we have to show what we consider a best practice so that
people can follow.
--
Stefano.
ntion, but if we
don't synch back, shit may happen and we want to avoid it.
What do you think?
--
Stefano.
ate your words to
summarize it.
I also think that a direct development link between apache and mozilla
might open the door for even more exciting opportunities in the future.
And having the cocoon community pave the road for this, would be very
exciting from both a software development and community development
point of view.
--
Stefano.
inevitable happens. I for one am
> reading every word you two write.
I'm with brother Geoff on this and have expressed my concerns in the
past already. I've also being discussing this with Ricardo and we were
going to "take a look" on synching back the continuation changes after
finishing the FOM (which has a higher priority, IMO).
So, no, you are not being paranoid but realistic in removing some of the
sand we are building on.
--
Stefano.
to set up the account? It has been about 2.5 days so far.
> I want to do it ASAP, but don't want to spoil the process.
There is no official duration of voting process and I would say that 48
hours with more than 3 positives votes and without a -1 is good enough.
These are lazy elections, let's keep them so.
--
Stefano.
nts that need mentoring by older communities to achieve
the long-term stability that is valued by both the ASF and by the users
who base their effort on the software the ASF produces.
- o -
Feel free to edit/add/change at will.
Wikifiers/docifiers are always welcome ;-)
--
Stefano.
l elements downstream of it as the pages are not
> cached.
>
> And that's why 301s are better if the page has moved permanently, but 302s
> are fine for a temporary change.
+1 for me.
--
Stefano.
ay, but
making it automatic could be too much.
what you all think about this?
--
Stefano.
r at work!
> I would also like to add a Garbage view to Petstore, but I need you to
> implement #include first ;)
Yeah, Pier, do you have a todo list for Garbage? maybe people can jump
in and help.
--
Stefano.
m.
Will it work? I don't know, but it's worth trying, expecially in a great
community like Cocoon's, there is a lot of ecosystem power and plenty of
social noise to feed the system and see what happens.
--
Stefano.
;re right, I overlooked that.
> Is there a method available in the FOM to do that?
In the new FOM there is a method to invalidate the session attached to
the session object, but it should be available even in the old FOM.
--
Stefano.
on 6/22/03 1:36 PM Christopher Oliver wrote:
> Agree. I've moved Database.js and related out of the core and into the
> scratchpad for now, until petstore gets refactored.
Thanks dude.
--
Stefano.
on 6/22/03 5:06 AM Christian Haul wrote:
> Stefano Mazzocchi wrote:
>
>>on 6/20/03 2:01 PM Christian Haul wrote:
>>
>>>Reinhard Pötz wrote:
>
>
>>>>*
on 6/22/03 3:07 AM Steven Noels wrote:
> On 22/06/2003 8:56 Upayavira wrote:
>
>
>>Just to clarify - Stefano was only suggesting removing input/output
>>modules from FOM, not Cocoon or the sitemap (where they are
>>appropriate).
>>
>>Do your comments still
gt; over time.
this is another problem and, IMO, it's a cultural thing as well: java
people tend to like to reinvent the wheel, just because coding in java
is easy and the WORA religion is a powerful engine.
> ->the java world seems to need amazing number of indians (or
> committers) relative to lines of codes or bugs fixed. And seems
> to see more isolated pockets of people than the xml and other
> parts of the ASF.
I don't get what you mean here, can you elaborate more?
--
Stefano.
>
>
>>Context object
>>--
>>
>>
>>>--parameters--
>>>getInitParameter(name)
>>
>>
>>If I interpret this correctly you would provide the web.xml
>>parameters as properties. Another possibility would be the
>>at
ave access to the
database connection avalon component directly from getComponent() and
the petstore can be changed accordingly. This would:
1) remove the need for database.js
2) keep concerns separate
3) avoid the need for a javascript extension concept that we planned
but never came to even design.
What do you think?
--
Stefano.
on 6/21/03 10:11 PM Geoff Howard wrote:
>>I propose Reinhard Pötz to be a Cocoon committer.
>
>
> +1
big +1!
--
Stefano.
- o -
Anyway, this gives you some background.
If you have any question, please, don't hesitate to ask me, possibly in
a public forum so that everyone can benefit from this information.
Thanks for listening.
--
Stefano.
imply copy the CVS repo I have here on
> betaversion, then, god knows!!! :-)
Great. Let Darwin and his wisdom take care of it. ;-)
--
Stefano.
nalization), focused on one thing (thus possible to optimize and
cache).
I welcome this effort with great happyness.
--
Stefano.
on 6/19/03 6:18 AM Matt Sergeant wrote:
> On Wed, 18 Jun 2003, Stefano Mazzocchi wrote:
>
>
>>>What about a stacktrace like this:
>>>
>>>Error occurred at:
>>>Java: org.apache.cocoon.components.SomeComponent.Configure:237:4
>>>Sitemap:
on 6/19/03 2:10 AM Ugo Cei wrote:
> Stefano Mazzocchi wrote:
>
>>Hey, wait a second. The ad-hoc namespace is added as a wrapper by the
>>request processing pipeline, it is *NOT* sent by the client code.
>
>
> I see. I'm still thinking that it's best
higher level of ASF participation.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
en then: Xalan fires trace events which are perfectly
> suitable for this job.
>
> So... how about it?
Yeah, how about it? does anybody have a clue on how we could implement
something like the above?
Anyway, dude, great RT, I love the concept, those mile-long stacktraces
aren't really giving us any useful information to trace where the real
problem is.
--
Stefano.
oday until I changed
>
> var mountpoint = requesturi.substring(1,requesturi.indexOf(sitemapuri));
>
> to
> var mountpoint = requesturi.substring(8,requesturi.indexOf(sitemapuri));
>
> inside flow.js
??? there is no such line in linotype/flow.js. Whick flow.js have you
modified?
--
Stefano.
on 6/18/03 3:56 AM Sylvain Wallez wrote:
> Gianugo Rabellino wrote:
>
>
>
>>BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we
>>aren't expecting anything less, so this is why you are not getting all
>>the kudos you deserve. :-) But it&
pload files from a browser, you have to use multipart-form
encoding. period.
What you can do is to encode your data as an XML file and send that, but
I really don't see the value of doing this instead of just POSTing a
bunch of parameters (which is as REST-ish as anything I can think of)
>
on 6/18/03 2:12 AM Ugo Cei wrote:
> Stefano Mazzocchi wrote:
>
>>No, no need for that. It took me half an hour to figure that problem out
>>myself and it's an indication of how generally badly designed is
>>cocoon's handling of multipart-encoded POST reque
on 6/17/03 3:54 PM Steven Noels wrote:
> On 17/06/2003 22:41 Stefano Mazzocchi wrote:
>
>
>>>I dropped the 'd' typo (I assume) from the offending line, and that one
>>>is gone. The 'save', 'revert' and 'delete' action aren&#
fter the concept had been proved. This is
exactly what we are doing right now.
> I'm only asking because I'm curious - no offense to anybody!
Well, thanks for asking, the more questions like these, the better.
If anybody else has something to add, please go ahead.
--
Stefano.
ns the component indicated by the
> given ID
>
>Here
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105405317918849&w=2]
>Stefano wrote: "Obviously, the flow will not have access to *all*
> components,
>but only to components that will
on 6/17/03 12:28 PM Ugo Cei wrote:
> Stefano Mazzocchi wrote:
>
>>Yes, basically all browsers that support Mozilla Midas API which, for
>>now are, Mozilla 1.3 or greater. Note that Midas is *NOT* part of
>>standard Gecko, so Camino won't do it.
>
>
> Hmmm,
vaScript exception: ReferenceError: "d" is not defined.
>>(file:/C:/cocoon-2.1/build/webapp/samples/linotype/flow.js; line 115)
>
>
> I dropped the 'd' typo (I assume) from the offending line, and that one
> is gone. The 'save', 'revert' and 'delete' action aren't working
> however, they bring me back to a new blog entry screen without doing
> what they should.
you didn't enable file uploading on web.xml
--
Stefano.
la 1.3, is that right?
>
>
> and I've got another issue upon posting an item:
>
> "file:/C:/cocoon-2.1/build/webapp/samples/linotype/flow.js", line 115:
> uncaught JavaScript exception: ReferenceError: "d" is not defined.
> (file:/C:/cocoon-2.1/build/webapp/samples/linotype/flow.js; line 115)
Typo. I'll fix it right away.
--
Stefano.
stefano 2003/06/17 10:24:06
Modified:src/blocks/linotype/samples flow.js
Log:
fixed typo.
CS: --
Revision ChangesPath
1.2 +1 -1 cocoon-2.1/src/blocks/linotype/samples/flow.js
Index
la Midas API which, for
now are, Mozilla 1.3 or greater. Note that Midas is *NOT* part of
standard Gecko, so Camino won't do it.
--
Stefano.
Damn, sent only to [EMAIL PROTECTED] Sorry
--
Stefano.
--- Begin Message ---
on 6/16/03 5:27 AM Matthew Langham wrote:
> To the Cocoon Community
>
> The involvement of commercial entities in an open source project can help
> tremendously with its success. If we look at the L
stefano 2003/06/16 18:31:12
Modified:.gump.xml
Log:
Linotype lands
Revision ChangesPath
1.62 +19 -1 cocoon-2.1/gump.xml
Index: gump.xml
===
RCS file: /home/cvs/cocoon-2.1/gump.xml,v
stefano 2003/06/16 18:12:43
Modified:.blocks.properties
Log:
Linotype lands
Revision ChangesPath
1.14 +2 -1 cocoon-2.1/blocks.properties
Index: blocks.properties
===
RCS file
stefano 2003/06/16 17:56:22
cocoon-2.1/src/blocks/linotype/samples/screens - New directory
stefano 2003/06/16 17:56:22
cocoon-2.1/src/blocks/linotype/samples/styles - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/repository/news - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/repository - New directory
stefano 2003/06/16 17:56:22
cocoon-2.1/src/blocks/linotype/samples/stylesheets/system - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/images - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/java/org/apache/cocoon/components - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/misc - New directory
stefano 2003/06/16 17:56:22
cocoon-2.1/src/blocks/linotype/samples/scripts - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/repository/news/2 - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/repository/news/1 - New directory
stefano 2003/06/16 17:56:22
cocoon-2.1/src/blocks/linotype/samples/stylesheets - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/samples - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/repository/news/template - New directory
stefano 2003/06/16 17:56:21
cocoon-2.1/src/blocks/linotype/samples/images/icons - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/lib - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/java/org/apache/cocoon - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/java/org/apache - New directory
stefano 2003/06/16 17:56:20
cocoon-2.1/src/blocks/linotype/java/org - New directory
stefano 2003/06/16 17:56:19
cocoon-2.1/src/blocks/linotype/java - New directory
stefano 2003/06/16 17:56:19
cocoon-2.1/src/blocks/linotype/conf - New directory
stefano 2003/06/16 17:56:19
cocoon-2.1/src/blocks/linotype - New directory
stefano 2003/06/16 16:46:10
Modified:src/java/org/apache/cocoon/generation RequestGenerator.java
Log:
improved RequestGenerator:
1) now comes with h: namespace prefix that makes it easier to process it in xslt
stylesheets that generate an output namespace which shouldn't h
that big of a deal, but I'm with you that the
concept sucks.
I really don't know what to say about this :-/
--
Stefano.
he FOM changed as to follow your
preferred methodology?
Please place your vote.
NOTE: even if you are not a user of the flow, your feedback is important
and will be appreciated.
Thank you.
--
Stefano.
on 6/15/03 3:53 PM Christopher Oliver wrote:
> Stefano Mazzocchi wrote:
>
>
>>Ovidiu wrote the FOM with "let's cover everything" mindset. He restated
>>the fact that he likes this approach better on his last mail to this list.
>>
>>The proble
on 6/15/03 6:42 AM Steven Noels wrote:
> On 15/06/2003 0:31 Stefano Mazzocchi wrote:
>
>
>> 1) I will try to patch the FOM for the proposed plan for June 24th.
>>
>> 2) If I can't do it, we release with what we have and we state loud and
>>clear that
on 6/14/03 3:52 PM Michael Wechner wrote:
> Stefano Mazzocchi wrote:
>
>
>>on 5/30/03 7:13 AM Upayavira wrote:
>>
>>
>>
>
>
>
>>>
>>>
>>
>>I'm back from my devastating, challenging yet superfun 2 week peruvian
&
OM for the proposed plan for June 24th.
2) If I can't do it, we release with what we have and we state loud and
clear that the FOM contract should be considered unstable and that might
change in future releases.
What do you think?
--
Stefano.
on 5/29/03 9:43 PM Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>
>>void callAction(name,map) -> invoques the action indicated by the given
>>name and pass the given map as model
>>
>
>
> How action returns its result?
you are right, the ab
ut what's inside.
>
> My 2 .
I'd like to see linotype as the seed for a micro-cms/blogger on top of
cocoon. I'll start with adding it to the CVS and let's see how things go
from there.
But again, enough talking, let's do stuff.
--
Stefano.
on 5/30/03 7:13 AM Upayavira wrote:
> Dear All,
>
> I would like to download and try Linotype, but can't find it. The page at:
>
> http://www.betaversion.org/~stefano/dist/linotype_1.0.tar.gz
>
> doesn't work. Anyone know where I can find it?
>
> Re
on 5/28/03 8:03 AM Christopher Oliver wrote:
> FlowVelocityGenerator to replace VelocityGenerator
Does it have any drawbacks? if not, +1 all the way.
--
Stefano.
on 5/28/03 7:29 AM Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>Here is what I propose to move:
>>
>> 1) ImageReader
>> 2) Paginator
>> 3) JXTemplate*
>>
>
> +1
>
>
>>anything else?
>
>
> Do we have any poli
1 - 100 of 2002 matches
Mail list logo
