, who came
up with the idea, and to Christopher Oliver, who implemented continuations
in Rhino. I just put all the things together and implement the support in
Cocoon.
A question about Christopher Oliver : is he using Cocoon, or is he using
the continuation-enabled version of Rhino
Ovidiu Predescu wrote:
In this example, both login() and addToCart() are functions that can be
called from the sitemap using map:call function=.../. The value of
all the global variables is essentially preserved, once the
createSession() function is called.
I'll commit an example of this
Hi Ivelin,
Actually I believe it is possible to have continuations in pure Java --
using bytecode rewriting -- however this approach is quite intrusive and its
effect on performance and code-size is not insignificant (see:
http://www.cs.kuleuven.ac.be/~tim/MOS/brakes.html). Nevertheless the
Hi Sylvain,
Sylvain Wallez wrote:
Christopher Oliver wrote:
Hi Ivelin,
Actually I believe it is possible to have continuations in pure Java --
using bytecode rewriting -- however this approach is quite intrusive and its
effect on performance and code-size is not insignificant (see
Ovidiu Predescu wrote:
Flow is designed to simplify the sitemap
by reducing the amount of routing components required and by moving
business logic out of the sitemap. Having global flow script variables
available to routing components might encouarage users to move the
flow/routing control
Ivelin,
Not sure if you realize this already, but you can use all those Java API's from the
flow layer if you need them. Rhino provides bidirectional interoperability with Java:
you can create java objects and call their methods from JavaScript, and you can extend
Java classes and implement
Ovidiu,
I think the below would also work, without changing system.js or any
Java code by using Rhino with continuations extended JavaScript syntax:
catch (continue) {
// The continuation I'm part of is about to be restored
// code to handle that goes here.
}
catch (break) {
// I'm
Hi Daniel
Daniel Fagerstrom wrote:
Interesting!! Could you tell a litle bit more about how this construct
works? What corresponds to the try block in ordinary exception handling
There is no corresponding try block in this case. See section 2.2 in
Ovidiu Predescu wrote:
Instead of putting in convenience features like this I think it
would be more valuable to make other view layers (Velocity, JSP's)
accessible to the flow layer. If someone familiar with the internals
of Cocoon wants to help me out I'd be interested in contributing to
Um, I think Daniel basically answered this question a long time ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=102052662705449w=2.
Sorry, I don't have an actual implementation, but I think it's clear
that the corresponding flow code would be much more readable than the
action code in the
provides an elegant solution compared to using actions. (Remember,
that was the objection you most recently raised).
Regards,
Chris
Ivelin
- Original Message -
From: Christopher Oliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, December 06, 2002 9:13 PM
Subject: Re: [Proposal
After you get it running, here's a link to some documentation for using
it: http://www.mozilla.org/rhino/debugger.html.
Regards,
Chris
Stefano Mazzocchi wrote:
Marcus Crafter wrote:
Hi All,
Hope all is well.
I've just checked-in support for using the Rhino JavaScript debugger
Uh, how useful is it to insist that something be fully implemented to
prove a point in a discussion on a mailing list? The purpose of my
example was to show that the flow layer allows you to avoid the
state-machine code required in XMLForm actions (which is what you
questioned in your original
Hi Ivelin,
Ivelin Ivanov wrote:
I have nothing new to add, but would like to balance the discussion
with a reminder:
- Original Message -
From: Ovidiu Predescu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, December 07, 2002 10:52 PM
Subject: Re: [Proposal] Implementing
Stefano Mazzocchi wrote:
Miles Elam wrote:
Stefano Mazzocchi wrote:
Look at what sendPageAndWait() is supposed to do:
1) create the continuation object
2) store it someplace
3) get its id
4) invoque the sitemap with the required URI
5) pass the invocation parameters and the
Ugo Cei wrote:
I've tried to implement this use case in a flowscript like the following:
function foobar() {
// Note the use of the new style function names
sendPageAndWait(showform, {});
// Collect request parameters here
sendPageAndWait(askforconfirmation, { /* ... field values ... */
Konstantin Piroumian wrote:
From: Ugo Cei [EMAIL PROTECTED]
It seems to me that Christian's version is more correct conceptually, it
allows to perform additional actions when user clicks Go back, while in
your version the flow engine will automatically return the flow to the
pervious state.
I've also had to try to solve the embedded compiling problem (for other
reasons) and I've also tried to use Pizza. Unfortunately, Pizza is very
poor quality code and has severe limitations that made it unusable for
me. Instead I've used the eclipse.org Java Development Tools compiler
(which is
OK. Done. I've placed the most permissive, non-copyleft license I could
find on this code.
Regards,
Chris
Nicola Ken Barozzi wrote:
Christopher Oliver wrote:
[...]
There is no license for the code I've written.
Please, add a license to it, possibly an Apache-derived license.
If code
Ovidiu Predescu wrote:
On Sunday, Dec 15, 2002, at 23:59 US/Pacific, Ugo Cei wrote:
Ovidiu Predescu wrote:
One solution would be to define a pseudo-continuation, just after
you finish the function initialization code, which could be referred
from the View page template. Something like:
Hi Jakob,
[EMAIL PROTECTED] wrote:
Your solution definitely looks nicer than mine!
-- and a somewhat other and larger project ;-)
Have you made a Cocoon hook for this? or should I try to give it a go?
Please do.
-
To
Hi Ugo,
Ugo Cei wrote:
function checkLogin(funarg)
{
if (user == null)
login();
funarg();
}
This doesn't seem to work. It always generates an error message like
org.mozilla.javascript.EvaluatorException: checkout is not a function.
But if I invoke the same function directly from
Ugo Cei wrote:
Christopher Oliver wrote:
Try this:
function checkLogin(funarg) {
if (user == null) {
login();
this[funarg]();
}
}
Thanks, it worked! While you're at it, would it be possible to pass
arguments to funarg, by defining them in the sitemap? I mean
Hi Reinhard,
Just a warning, you should always use the var keyword with local
variables in JavaScript. Your function should probably read:
function callPipeline(src) {
var xc = cocoon.componentManager.lookup( myXMLConsumer.ROLE );
var resolver =
As I mentioned before
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103990910724056w=2), it's possible
to do embedded compiling without the limitations of javac. See
ftp://ftp.primaryinterface.com/pub/javacAPI
Regards,
Chris
-Original Message-
From: Pier Fumagalli [mailto:[EMAIL
Unfortunately, it doesn't.
Sylvain Wallez wrote:
Tony Collen wrote:
On Thu, 30 Jan 2003, Nicola Ken Barozzi wrote:
We didn't understand what he was doing, but he seemed so passionate
about it that we could not get together the courage to stop him. Then
somehow he finally understood that
The workaround for using javascript keywords (like delete) as property names is to use
the [] notation instead of ., i.e.:
myClass[delete](objectToDelete);
Regards,
Chris
-Original Message-
From: Fabio Sabatini [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 10:50 AM
To:
I believe Tomcat makes this work via the following hack:
Requiring that class loaders are URLClassLoaders (containing file
resources) in a three-level arrangement
Common
|
Shared
|
WebApp
Then before executing javac it walks up the
was told to me by a friend of
mine, Florin Mihaila, who read about it in a paper by Christian
Queinnec (http://youpou.lip6.fr/queinnec/WWW/Queinnec.html).
Christopher Oliver was very instrumental in implementing continuations
in Rhino. Without his excellent work, patience and attention
Just wondering, why isn't the average cocoon user reluctant to write
complex xpath or xslt code as well as Java?
Regards,
Chris
Sylvain Wallez wrote:
This is a good idea when you need to use the JavaBean for some
business logic. But there are many cases where you just want to
populate a
Oliver surely is on to something
more viable with his JavaCAPI - but for the time being, the pizza
compiler works great here at my company.
I asked Christopher Oliver whether it was OK for me to integrate his
JavaCAPI into cocoon - and he said it would be cool; but due to too
much work and a rather
Wallez wrote:
Christopher Oliver wrote:
Actually I am in the process of trying to do this but got immediately
stopped by the below when I first tried to run cocoon (built from
today's cvs),
Anyone care to help?
Regards,
Chris
ERROR (2003-02-16) 13:12.15:159 [access]
(/cocoon/documents
Yes, adding xsltc-X.jar to common/endorsed fixed that problem. But
what exactly caused it in the first place? Can someone explain?
Regards,
Chris
Ugo Cei wrote:
Christopher Oliver wrote:
Sylvain,
Can you explain the connection between Xalan.jar, the endorsed
directory, and the error
)
Regards,
Chris
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
Actually I am in the process of trying to do this but got immediately
stopped by the below when I first tried to run cocoon (built from
today's cvs),
Anyone care to help?
Regards,
Chris
ERROR (2003-02-16) 13:12.15:159
Heinicke wrote:
Not exactly, but the JDK 1.4 comes with older versions of Xalan,
Xerces and so on and there seem to be some incompatibilities. And
normally JDK classes are loaded first = the well-known endorsed problem.
Joerg
Christopher Oliver wrote:
Yes, adding xsltc-X.jar to common
Unfortunately 1.4.0 on windows appears to be also, since that's what I'm
using. Have you had success using a java debugger with Cocoon?
Regards,
Chris
Peter Royal wrote:
On Monday, February 17, 2003, at 12:40 PM, Christopher Oliver wrote:
Yes, we should report this bug to tomcat-dev
Attached is a first try at integrating XMLForm with the Cocoon Flow
layer. Since I'm not an expert on XMLForm or XForms (or Cocoon for that
matter!) it's likely to have limitations or defects so keep that in mind.
The attached files provide an implementation of the XMLForm Feedback
Wizard
Ugo Cei wrote:
I didn't try the sample, since it's 1AM and I'm going to bed, but just
by looking at the code, I have a couple of observations:
XForm.sendView(view, uri) // Sends view to the
presentation pipeline and waits for the form to be submitted (and
automatically resends
It appears that XMLForm's use of JXPath is hardcoded to setting indexed
values only on Java arrays and Collections (not DOM nodes or other types
of JXPath nodes). I was attempting to use a JavaScript object as a
JXPath node, but ran into the below problem in Form.java
()
- Dmitri
--- Christopher Oliver [EMAIL PROTECTED] wrote:
It appears that XMLForm's use of JXPath is hardcoded to setting
indexed
values only on Java arrays and Collections (not DOM nodes or other
types
of JXPath nodes). I was attempting to use a JavaScript object as a
JXPath node, but ran
Ugo, I will shortly commit changes that will allow you to use any
JavaScript object (in addition to Java beans) as the model for an
XMLForm. Attached is an example of the feedbackWizard sample using a
pure JavaScript model. Of course, you can also embed Java objects inside
the JavaScript
Ugo Cei wrote:
Christopher Oliver wrote:
Ugo, I will shortly commit changes that will allow you to use any
JavaScript object (in addition to Java beans) as the model for an
XMLForm. Attached is an example of the feedbackWizard sample using a
pure JavaScript model. Of course, you can also embed
I've committed changes to support using the Cocoon flow layer with
XMLForm, which includes a flow-based version of the XMLForm feedback
sample wizard (http://localhost:/samples/xmlform/flow), that you'll
be able to try yourself as soon as someone fixes the build for the
samples in cvs ;)
ivelin wrote:
Chris,
I am trying to get my hands around your code.
I see the function which loops until there are no more input violations and
although I have a guess about the response, I would still like to hear from
you on these questions:
Where would you place calls to the backend which for
Any suggestions on how to document this stuff:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104604489704318w=2 ?
To write an XMLForm application with the flow layer involves at least:
1) Writing XForm documents for each of the pages in your Form
2) Writing a schematron script that describes
ivelin wrote:
Chris,
I am trying to get my hands around your code.
I see the function which loops until there are no more input violations and
although I have a guess about the response, I would still like to hear from
you on these questions:
Where would you place calls to the backend which for
Hi Martin,
You have an old version of JXPath in your classpath. Search for and
remove commons-jxpath-1.0.jar. This has been superceded by
commons-jxpath-1.1b1.jar.
Note that in this case the compile-time error caused by import .* is
actually beneficial. If not for that you would get a runtime
I've just committed changes to support using the Eclipse JDT compiler
(http://www.eclipse.org/documentation/html/plugins/org.eclipse.jdt.doc.isv/doc/reference/api/index.html)
as an embedded Java compiler for Cocoon.
To use this compiler modify your cocoon.xconf like this:
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
I've just committed changes to support using the Eclipse JDT compiler
(http://www.eclipse.org/documentation/html/plugins/org.eclipse.jdt.doc.isv/doc/reference/api/index.html)
as an embedded Java compiler for Cocoon
for improvement?
-=Ivelin=-
- Original Message -
From: Christopher Oliver [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, February 21, 2003 4:10 PM
Subject: Re: Setting values in XMLForm (via JXPath)
In this case it looks like XMLForm is trying
I've just committed changes to support calling Velocity
(http://jakarta.apache.org/velocity) from the Cocoon flow layer.
In order to not break any existing users of the VelocityGenerator, I've
created a new generator:
org.apache.cocoon.generation.FlowVelocityGenerator
This generator differs
I've just committed [experimental] changes that provide a simple
database API for the Cocoon flow layer modeled after JSTL
(http://java.sun.com/products/jsp/jstl). This will allow you to perform
a database query in a flow script that produces a bean-like object for
use by your presentation
First of all Sylvain, my name is Chris Oliver, not Andrew C. Oliver
(that's [EMAIL PROTECTED]).
Sylvain Wallez wrote:
Hi all,
A rather provocative subject, so let me first say that I like the flow,
even if unfortunately I didn't have the occasion to use it up to know.
Ovidiu did a wonderful
Sylvain Wallez wrote:
Christopher Oliver wrote:
The cocoon object now supports a new function
getConnection([String] dataSourceName);
This looks cool... but, continuing my rant about oversimplification, why
does the _cocoon_ object hold methods to access database connections ?
AFAIK
(productList.limitedByMaxRows);
}
// etc ...
I believe if used properly this can still provide the correct SOC. What
do you think?
Regards,
Chris
Gianugo Rabellino wrote:
Christopher Oliver wrote:
I've just committed [experimental] changes that provide a simple
database API for the Cocoon flow layer modeled
Pier Fumagalli wrote:
On 4/3/03 0:52, Christopher Oliver [EMAIL PROTECTED] wrote:
You know what? You're right. My description below was wrong. What I
should have said is that I created a simple _JavaScript_ database API
that can be used to implement business objects in JavaScript.
Nononono
Pier Fumagalli wrote:
On 3/3/03 20:57, Christopher Oliver [EMAIL PROTECTED] wrote:
I don't see the point in extending the core functionality of the flow,
dealing with cocoon pipelines and requests, when this should be only an
external layer which can be _easily_ implemented by writing one tiny
Antonio Gallardo wrote:
Hi Christopher:
I think that the point they tried to show us is that the database
functions can be an optional part of all the Flow block. I agree because
some applications will not need to use databases at all.
Yes, clearly, that is the case. However, there isn't yet a
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
3) no higher level functionality should be added without a previous
RT/proposal/vote cycle.
I'm perfectly aware of the fact that this will reduce the freedom of
people like Chris to innovate and show potentially creative new uses
of the flow. For
Stefano Mazzocchi wrote:
Some like the flow, some don't know it enough to dislike it but won't
try it out until we have a release. In the meanwhile, we are adding
functionality without stabilizing it.
I believe we should work toward release Cocoon 2.1, this is our priority
at the moment:
Jakob Praher wrote:
Am Die, 2003-03-04 um 18.52 schrieb Christopher Oliver:
Not sure. This is one of the weaknesses of JavaScript. It doesn't have
any structuring mechanism for creating libraries or reusable modules
(which was one of the things JavaScript 2.0 was supposed to fix). I
think
: Stabilizing flow in order to release
On 4/3/03 22:08, Christopher Oliver [EMAIL PROTECTED] wrote:
Jakob Praher wrote:
Am Die, 2003-03-04 um 18.52 schrieb Christopher Oliver:
Not sure. This is one of the weaknesses of JavaScript. It doesn't have
any structuring mechanism for creating libraries
Pier Fumagalli wrote:
Back to the drawing board, my fellow IDL editor at hands, and I start doing
one weird thing: converting the flow object model into IDL, as the current
JavaDOC output of JSCocoon and friends doesn't look easy and nice,
preventing me to visually see if it's an implementation
Pier Fumagalli wrote:
On 5/3/03 7:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Pier Fumagalli wrote:
I know... But where can I read it? Where will our users be able to see that
all those function they rely on are actually implementation details and
that they shouldn't even touch them
Pier Fumagalli wrote:
On 5/3/03 14:52, Christopher Oliver [EMAIL PROTECTED] wrote:
It should be documented that the rest are private and as a normal user
of the flow layer I think you probably shouldn't be using them.
So, can I please ask to everyone not to hack around the flow O/M before
Pier Fumagalli wrote:
It would be kool to take a look at it... But bear in mind that part of the
OM for the flow is written in JavaScript (system.js), and part in Java
(o.a.c.c.flow and o.a.c.c.flow.javascript packages)... The _best_ thing
would be to have an IDL javadoc...
Pier
Try these,
OK. Following Pier's approach, I've also tried to start documenting the
Cocoon Flow Object Model everything that is currently under
flow/javascript in CVS - whether I think it should be there or not -
using IDL and generated JavaDocs using openorb's idldoc.
The idl is here:
I think you're right. It shouldn't remove the session.
-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 06, 2003 2:48 PM
To: [EMAIL PROTECTED]
Cc: Christopher Oliver
Subject: [Flow] XForm.finish unnecessarily removes session
In the Flow's system.js script
Pier,
If you want the IDL for Java classes you could try using the rmic
compiler that comes with the jdk. Just do
rmic -idl java.io.OutputStream
for example.
Otherwise, I don't think you need a JavaObject, etc. You can just do
module java {
module lang {
interface Object {
Just wanted to let people know that thanks to Steven Noels and Ovidiu
the Rhino interpreter with continuations recently got a CVS repository
at cocoondev.org:
http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/rhino1_5R4pre
Regards,
Chris
Hi Vadim,
The EclipseJavaCompiler is currently hardcoded with source=1.4 and
target=1.4. This is because I didn't know how to configure those
properties through the available Cocoon interfaces. There is nothing
wrong with the Eclipse compiler itself, only with my code. Either we can
hardcode
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
Just wanted to let people know that thanks to Steven Noels and Ovidiu
the Rhino interpreter with continuations recently got a CVS repository
at cocoondev.org:
http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/rhino1_5R4pre
That's very good.
BTW
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Hi Vadim,
The EclipseJavaCompiler is currently hardcoded with source=1.4 and
target=1.4. This is because I didn't know how to configure those
properties through the available Cocoon interfaces. There is nothing
wrong with the Eclipse compiler
Stefano Mazzocchi wrote:
BTW, do you have any news on the merging your patches into the main
rhino tree at mozilla.org?
Honestly, I don't think that will happen any time soon. My changes
were based on a snapshot from March of last year. During that time one
of the Rhino developers has
It just indicates whether the compiler should accept java 1.4 source
extensions like assert. It's equivalent to:
javac -source 1.4 ...
Vadim Gritsenko wrote:
Christopher Oliver wrote:
OK. But, I think you should also set the source version. What do you
think?
I was (and still am) not sure
Stefano Mazzocchi wrote:
The discussion is about making the flow a technology that cocoon can
depend on for years.
And this passes thru stabilizing the contracts between the flow
scripters and the cocoon internals.
And I want this to be done by a community, not by only the few
developers that
I've made a first cut at implementing the Java PetStore example
application using Cocoon. I started by converting the Ibatis PetStore
(https://sourceforge.net/projects/ibatisjpetstore) which is struts-based
to use the Cocoon flow layer (and converted its jsp's to velocity
templates).
I could
leo leonid wrote:
I never used velocity templates so far. In order to get your snapshot
running (so far I get a ConfigurationException: Type 'flow_velocity' is
not defined) I wanted to have a look at the velocity-cocoon samples.
Unfortunately the are not available in the latest 2.1 CVS build.
Here's a summary of some of the recent issues with the Flow for discussion:
1) Storing the flow context object and continuation in environment
attributes:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104673257019781w=2
This seems easy to fix. But I personally don't understand the
leo leonid wrote:
Eventually, I'd like to add this to the flow samples, but in the
meantime if anyone is interested in helping, let me know and I'll
check it into the scratchpad. (Unfortunately the scratchpad samples
are still broken though).
Please do. A sample like this would be sufficient
It may not help you at the moment because its still under development,
but with the current XMLForm integration with the Cocoon flow layer, you
can also do validation in JavaScript, meaning you have regular
expressions, String operations, etc, the full power of JavaScript and
Java, if you need
leo leonid wrote:
On Freitag, März 14, 2003, at 07:45 Uhr, Christopher Oliver wrote:
the views are pretty much brain-dead: Velocity generating xhtml
directly. It would be neat if we could better show off Cocoon's view
generation capabilities - but I suck at that type of thing.
Anyway, any
leo leonid wrote:
On Freitag, März 14, 2003, at 07:45 Uhr, Christopher Oliver wrote:
the views are pretty much brain-dead: Velocity generating xhtml
directly. It would be neat if we could better show off Cocoon's view
generation capabilities - but I suck at that type of thing.
Anyway, any
I didn't find anything in Eclipse bugzilla. The reports on cocoon-dev
about this seem to all be coming from MacOS X. I glanced at the code and
I don't see an obvious problem (look at readTable(String filename) in
Found it:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=34658#c28
Pier Fumagalli wrote:
On 16/3/03 23:40, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Christopher Oliver wrote:
I didn't find anything in Eclipse bugzilla. The reports on cocoon-dev
about this seem to all be coming from MacOS X
Sylvain Wallez wrote:
A short explanation about the object model. Cocoon abstracts its
runtime environment through the Environment interface. An Environment
object gives access to a number of things that are relevant to the
pipeline/sitemap engine only and should not be visible from other
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
leo leonid wrote:
On Freitag, März 14, 2003, at 07:45 Uhr, Christopher Oliver wrote:
the views are pretty much brain-dead: Velocity generating xhtml
directly. It would be neat if we could better show off Cocoon's view
generation capabilities
Thanks. My bad.
[EMAIL PROTECTED] wrote:
vgritsenko2003/03/16 17:16:19
Modified:src/scratchpad/webapp/samples/petstore/flow PetStoreImpl.js
Log:
Fix petstore sample
Revision ChangesPath
1.3 +1 -1
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
snip/
So we need two more values in the object model Map : one for the
value dictionary, and one for the continuation.
How does it sound ?
That would work.
Excellent! I've grepped sources, seen those awful
Pier Fumagalli wrote:
On 17/3/03 2:06, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Practical proposal:
* Add flow-continuation to the objectModel, and getter method to the
ObjectModelHelper, as a replacement for kont environment attribute.
Read only properties of the script (global) ??? Or
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Right now VelocityGenerator exports (as per javadoc):
* dtrequest (org.apache.cocoon.environment.Request)/dt
* ddThe Cocoon current request/dd
*
* dttemplate (java.lang.String)/dt
* ddThe path of the template file currently being evaluated/dd
Vadim Gritsenko wrote:
Here you will have to explain to me why: Why whould you want to pass
*only* this bean?
Because that is the contract between the flowscript and the
presentation layer.
And I still have question why don't you put this bean into request
attributes? And why have such bean in
Vadim Gritsenko wrote:
Christopher Oliver wrote:
That's not the case. All are equally crippled ;) For example, when
using Xsp, the idea is that the only logic sheet you will ever use is
the jpath logic sheet. This does not give you direct access to
session, request, or context but only
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Here you will have to explain to me why: Why whould you want to pass
*only* this bean?
Because that is the contract between the flowscript and the
presentation layer.
In Cocoon apps, presentation layer is usually XSL
leo leonid wrote:
I just put the first results on my server.
= http://proto2.leonid.de
The XSP/XSL view for browsing Categories, Products, Items, Search,
SignOn is already working. I'm now a bit stuck with the Cart, where I am
still unsuccessful in retrieving values from the flow layer via
Vadim Gritsenko wrote:
Christopher Oliver wrote:
You may discourage usage of these objects for the sake of perfectness of
the MVC in the documentation but I don't think you should insist on
disabling access to them (like in FlowVelocityGenerator).
Fair?
Vadim
I think you're right.
JSTL
leo leonid wrote:
excellent! so I can go on with checkout, order, shiping, etc...
Does Xsp have some way of doing number formatting? The numeric values
you receive from JavaScript are of type java.lang.Double.
Yes probably there is already a logicsheet for this, I try to avoid
xsp:logic/.
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
Upayavira wrote:
I am somehow aware that I am abusing sessions here, and that there
is a better way, but it's not that easy to follow, probably. If you
can show it to me, I'd be glad to abandon sessions, but if you take
them away right now, I'm going to be in trouble ;-).
Great, integration
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a *real*
need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed in Ugo's case.
+1 for a
1 - 100 of 175 matches
Mail list logo
