Joerg Heinicke schrieb:
I'd like to introduce some people of our community and invite them for
becoming committers of the Cocoon project.
1. Andreas Hochsteger
+1
2. Peter Hunsberger
+1
3. Jason Johnston
+1
Guido
Sylvain Wallez schrieb:
I'd like to propose Simone Gianni for Cocoon committership.
+1
Guido
Daniel Fagerstrom schrieb:
I'd like to propose Niclas Hedhman as a new Cocoon committer.
+1
Guido
ite.
Although I have the slight feeling that such a discussion may be doomed
to lead to nowhere I thought the subject of Cocoon 3.0 would justify it.
I hope you agree and bare with me :-)
Guido
--
Freundliche Grüße / With kind regards
Guido Casper
S&N AG
Competence Center Open Source
Klingenderstr. 5
D 33100 Paderborn
voice +49 5251/1581-87
fax+49 5251/1581-71
eMail [EMAIL PROTECTED]
Webhttp://www.s-und-n.de
Sylvain Wallez wrote:
I'd like to be the voice of a general opinion among Cocoon developers
that Arjé Cahn should be made a Cocoon committer.
+1
Guido
Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
+1
Guido
omewhat stalled. I'm myself guilty of one of those and if I
don't find time to continue to work on it RSN I'll go for removing that
one from SVN to reduce confusion.
Guido
--
Freundliche Grüße / With kind regards
Guido Casper
S&N AG
Competence Center Open Source
Klingenderst
Sylvain Wallez wrote:
Please cast your votes.
+1
Guido
Carsten Ziegeler wrote:
So, please cast your votes!
+1
Guido
Bertrand Delacretaz wrote:
This may be a little off topic and I'm asking out of curiosity what
others think. But I wonder if flow (and continuations in particular)
and cforms really is an appropriate technology for "rich" (and
potentially stateful) clients?
It's hard to say without having a con
Bertrand Delacretaz wrote:
Le 23 nov. 04, à 10:53, oceatoon a écrit :
...Is different JS really coded for different browsers? I thought
there were
only those with JS and those without, in the second case validation would
go back to Server Side but no different version of scripts...
your (future)
Bertrand Delacretaz wrote:
Le 18 nov. 04, à 00:43, Ugo Cei a écrit :
hmm.. are you testing on macosx and seeing this sometimes only?
No, on Linux. And it seems to be repeatable.
You're right, sorry. I see the same here on macosx ad webdav-step3.xml:93.
Works here (WinXP). Hmm, really strange (gi
Torsten Curdt wrote:
Folks please cast your votes for:
[ ] Leszek
[ ] Ralph
as Apache Cocoon committers.
+1 for both.
Guido
Ralph Goers wrote:
In short, the fact that Cocoon is just a bunch of parts that get
configured is one of Cocoon's major strengths. However, the current
configuration is pretty easy to understand and modify. If the
replacement container makes the configuration more complex and less
understanda
Sorry, I thought what's being discussed is wether or not to use Spring
as an intra-block container and that Tani as inter-block container is
set. Am I wrong?
Guido
Bertrand Delacretaz wrote:
The point that I was trying to make is that I really like the idea of
considering the "cocoon core" container separately from the "cocoon
applications" one, as much for marketing reasons as for technical ones.
I too like the idea.
Guido
Guido Casper wrote:
Don't you like Spring's way of DI?
Sorry Bertrand, ignore that, of course you already told you like it.
May mail wasn't (only) addressed at you :-)
Guido
Bertrand Delacretaz wrote:
Le 16 oct. 04, à 11:14, Guido Casper a écrit :
...for a start it would be the easiest to just drop in
spring-core.jar. But we would have to make sure, that this cannot be
interpreted as an invitation to introduce other dependencies
Dependencies on Spring in the
Ugo, can you explain what exactly are the dependencies on Spring? My
rather limited) understanding is, that we primarily would use Spring's
BeanFactory. As the BeanFactory is:
a) designed to not introduce any dependency for your components
b) rather trivial to re-implement
for a start it would b
Ugo Cei wrote:
Guido Casper wrote:
Added:
cocoon/whiteboard/butterfly/lib/js-1.6R1pre.jar (contents, props
changed)
Log:
Added Rhino jar
Ugo, what does Spring use that for? Do you have any pointers?
Spring 1.2 will have the possibility of managing not just regular Java
beans, but also
[EMAIL PROTECTED] wrote:
Author: ugo
Date: Thu Oct 7 14:15:48 2004
New Revision: 54018
Added:
cocoon/whiteboard/butterfly/lib/js-1.6R1pre.jar (contents, props changed)
Log:
Added Rhino jar
Ugo, what does Spring use that for? Do you have any pointers?
Thanks
Guido
intained?
Thanks for your help.
Guido
Antonio Gallardo wrote:
Guido Casper dijo:
Antonio Gallardo wrote:
Hi, while cheking for some updates, I found that the xmldb site is down:
http://www.xmldb.org/
Can someone tell where is the site now?
http://marc.theaimsgroup.com/?l=xindice-users&m=1086542
Antonio Gallardo wrote:
Hi, while cheking for some updates, I found that the xmldb site is down:
http://www.xmldb.org/
Can someone tell where is the site now?
http://marc.theaimsgroup.com/?l=xindice-users&m=108654200411626&w=2
Guido
Niclas Hedhman wrote:
Looking at the actual differences;
public AbcComponent( org.hedhman.niclas.SomeDependency some )
{
m_SomeDependency = some;
}
/** @avalon.dependency type="org.hedhman.niclas.SomeDependency"
* key = "some"
*/
public void service(ServiceManager man )
{
m_SomeDepend
Leszek Gawron wrote:
Guido Casper wrote:
One thing to keep in mind is that the sitemap is a declarative thing
(and the pointy brackets always remind us of that). While skripting the
I think this is not true. For those who do not use flowscript sitemap
became a "programming language&qu
First let me say that I'm really excited by your work. Thanks for that!
Ugo Cei wrote:
Il giorno 28/lug/04, alle 04:02, Vadim Gritsenko ha scritto:
Why stop half way and live with one more interpreter's penalty?
Convert straight to Java - works faster and less memory consumption!
And we are back o
Reinhard Poetz wrote:
Unico Hommes wrote:
Guido Casper wrote:
Sorry, I think I was not clear (my fault). I intended the vote to be
about marking (like within javadocs) either:
-internal classes
or (the opposite):
-published classes
The first is what Vadim suggested and most simple to do (there
Unico Hommes wrote:
Guido Casper wrote:
Guido Casper wrote:
Vadim Gritsenko wrote:
In all other situations, Carsten is right - this might cause
backward incompatibility. This is important for user-facing classes.
Should we start marking classes as internal, like
"INTERNAL!!!" in javad
Guido Casper wrote:
Vadim Gritsenko wrote:
In all other situations, Carsten is right - this might cause backward
incompatibility. This is important for user-facing classes. Should we
start marking classes as internal, like "INTERNAL!!!" in
javadoc or some such?
What about i
Vadim Gritsenko wrote:
In all other situations, Carsten is right - this might cause backward
incompatibility. This is important for user-facing classes. Should we
start marking classes as internal, like "INTERNAL!!!" in javadoc
or some such?
What about introducing @cocoon.usage tags I proposed a
Ugo Cei wrote:
Dear Cocooners,
I've just started to take a look at the JCR (a.k.a. JSR-170) Reference
Implementation from Slide, after having read the latest JSR draft, and I
feel like exploring the possibilities of its usage inside Cocoon.
First thing I tried to do is an implementation of the
Carsten Ziegeler wrote:
Guido Casper wrote:
Does anyone (besides me) think the distinction between
published and non-published classes/interfaces is a useful
thing? IMO it's a pity that the Java language doesn't provide
any means for that.
Yes, makes sense to me. Could we add the ta
think the distinction between published and
non-published classes/interfaces is a useful thing? IMO it's a pity that
the Java language doesn't provide any means for that.
Is there a better way/format for generating docs for that?
Guido
Carsten
-Original Message-
From: Guido Casper
.
So I decided to base the task (mostly taken from the QDoxSource
currently) on QDox, being already part of the build and tools/lib anyway
(but I'm open to suggestions).
WDYT?
Guido
--
Guido Casper
-
S&N AG, Competence Center Open
Rolf Kulemann wrote:
On Wed, 2004-05-19 at 09:10, Guido Casper wrote:
Rolf Kulemann wrote:
What u mean with Repository block? IMHO there are currently two
approaches hosted within the repository bloch, which should be divided
normally.
1.) SourceRepository which acts on various interfaces like
implementation which is
too flow oriented (no exception handling etc.)
These 2 (interfaces) are not all that different (like different
approaches) and I plan to merge them.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open So
understands the implications of taking one block or the other...
And my
last question: .what version of Slide is currently integrated in Cocoon?
2.0
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-
that component (and added to the index etc.)
+1 for both.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Stefano Mazzocchi wrote:
Guido Casper wrote:
Once such a customized doclet mechanism is in-place (Does someone know
wether QDox already has an Ant task? Or maybe we should use XDoclet
for that?) it may easily be extended for "some kind of" flowscript-API.
are you volunteering? ;-)
Stefano Mazzocchi wrote:
Guido Casper wrote:
Yes, I realized that flowscript is the perfect solution to the missing
piece of the pyramid of contracts for the webapp space.
I just feel we should much more leverage it for this role and it is
vital to give more emphasis to the user.
I'm
Leon Widdershoven wrote:
Guido Casper wrote:
Yes that might be one reason. Another one IMO is that it's much easier
to (conceptually) come up with a reusable sitemap component (being a
specialized thing) than it is to come up with a reusable flow component.
Guido
I think that is the
something more "flowscript-supportive".
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
rations too.
The question is whether we don't duplicate the efforts of e.g. OJB with
this approach? The only difference is that you don't need Java objects ...
Best Regards,
Antonio Gallardo
--
Guido Casper
-
S&N AG, Competence Cente
systems to
enforce your latest notion of best practices.
Tim, don't take the word for everything said in a RT thread and don't
worry that access to Java will be disabled in the 2.x branch (if ever)
as this certainly would break any production system running on with flow.
Gu
Hunsberger, Peter wrote:
Guido Casper <[EMAIL PROTECTED]> writes:
As I alway try to keep my flowscript as "exception-handling-free" as
possible and as I feel that this sentiment is not shared by
everyone, I
thought it is a good oportunity to come up with another concern.
Antonio Gallardo wrote:
Guido Casper dijo:
I think that cocoon.getComponent(role) would be enough if writing those
components would be as painless as writing flowscript. No need for more
complex stuff.
I don't think developers aren't eager to write reusable components. But
currently
rfect solution to the missing
piece of the pyramid of contracts for the webapp space.
I just feel we should much more leverage it for this role and it is
vital to give more emphasis to the user.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
ch should always be high level and easy to be
used by users) and provide some kind of doclet mechanism that generates
the docs for our "official" flowscript API.
The reason I'm thinking about this is that I wondered wether the
repository block justifies its existence now that we are s
Ugo Cei wrote:
Guido Casper wrote:
Ugo Cei wrote:
WebDAVRepository.java (swallowed):
} catch (ProcessingException pe) {
this.getLogger().error("Error saving dom to: " + this.repoBaseUrl
+ uri, pe);
}
WebDAVRepositoryPropertyHelper.java (swallowed):
} catch (ProcessingEx
ror("Error serializing node " + value, pe);
}
Ehm, I didn't follow all the discussions very closely, but if you want
to remove something please be aware that these Exceptions are not just
swallowed (don't know about the others) since after the catch clause
follows a "re
Stephan Michels wrote:
The current webdav methods are:
... SUBSCRIBE UNSUBSCRIBE
POLL EVENT TRANSACTION ...
Where do these come from? They are not webdav methods.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open So
Stephan Michels wrote:
Am Mi, den 14.04.2004 schrieb Guido Casper um 9:08:
Stephan Michels wrote:
The Repository IFs seems be more helper classes than components. And I
think we should using the Source objects instead to reflect all aspects
like locking, property handling etc.
Care to elaborate
Sources (which
BTW is their original intention) and modifying operation via Repository
- quite useful.
However I use flowscript (which I suspect you don't like :-) for that.
Guido
--
Guido Casper
-
S&N AG, Competence Center Op
IIUC).
So what you might want to do is to create a DASL searcher (like the
DASLTransformer?).
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-3
one and only interface to repositories (of
all sizes and needs) then this particular component may be mostly
redundant as having a portability layer becomes pointless.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
The way WebDAV is designed (and the way lock tokens work) allows both
"session-internal-only" locking behaviour or "user-centric" locking
behaviour. The difficulties in managing locking state are due to the way
WebdavResource works.
http://marc.theaimsgroup.com/?l=slide-dev&m=108057214410350&w=
Stephan Michels wrote:
Am Do, den 08.04.2004 schrieb Guido Casper um 20:18:
Stephan Michels wrote:
What the status of the WebDAVSource? It seems that it doesn't implement
any versioning. Or am I wrong?
No. I (vaguely) remember some discussion considering your
VersionableSource vs. Sylv
Stephan Michels wrote:
Am Do, den 08.04.2004 schrieb Guido Casper um 17:08:
Rolf Kulemann wrote:
Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from
s say "all child nodes" of
a collection/node using the repository interface? Or is it a concern of
a RepositorySource?
No, some mechanism to retrieve collection members (getChildren() or
getMembers()) would be a welcome addition to the Repository interface IMO.
Gu
Rolf Kulemann wrote:
Looking at the repository block, one will see that there is already a
RepositorySource, but that source and the RepositorySourceFactory are
not meant to be used with the new Repository interface from Guido.
What I have in mind is:
A new RepositorySourceFactory should simply lo
Rolf Kulemann wrote:
On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
Rolf Kulemann wrote:
[Related to http://issues.apache.org/bugzilla/show_bug.cgi?id=28189]
As for WebDAVRepsoitoryVersioningHelper.setVersioned(): I don't think it
is a good idea to throw an
UnsupportedOperationExce
implemented by:
-copy to a temporary resource
-check wether the temporary resource is version-controlled
-move the temporary resource back overriding the original resource
We also need to set appropriate locks if supported, imho.
Yes.
Guido
--
Guido Casper
Rolf Kulemann wrote:
On Mon, 2004-04-05 at 13:38, Guido Casper wrote:
Rolf Kulemann wrote:
I just changed the code a little bit. However it's now a little hacky
and needs completion as after the copy you should check wether the
destination is version controlled and if that's the cas
's the case undo the move
(to keep the old version history) and return false.
I don't know the details of how to check wether a resource is under
version control right now (would have to check the DeltaV spec).
Guido
--
Guido Casper
-
S&
Rolf Kulemann wrote:
On Sun, 2004-04-04 at 17:00, Guido Casper wrote:
Rolf Kulemann wrote:
Hello (Guido),
I have done a small js file to test the functionalities of the new
WebDAVRepository[1] using the NEW Repository[2] interface.
I encountered a problem creating new reosurces.
It does not
,
boolean create) etc.
Makes sense? Or have I missed a way to create a new resource?
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn
Is everybody fine with moving FlowAttributeModule and
FlowContinuationModule from scratchpad to core? Is a vote needed? I
guess no.
If noone objects I go ahead tomorrow.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open So
.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Rolf Kulemann wrote:
On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
-link management
What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
explain your idea in more detail.
I'm thinking of managing linking information within metadata/properties
in a bidirectional w
Rolf Kulemann wrote:
On Fri, 2004-04-02 at 08:34, Guido Casper wrote:
On top of this other higher level components might be build. Among the
things I have in mind are:
-a document store accommodating a certain array of use cases and being
simple to use from the flow layer (in fact there might be
Rolf Kulemann wrote:
On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
Concerning the repository ... I just committed another repository
interface :-) that tries to be a best effort in consolidating all the
different approaches and accommodating all concerns in a flexible way
(by having opional
Ugo Cei wrote:
Fellow Cocooners,
after having neglected my weblog for a long time, I'm starting to feel
the urge to blog again, but I want to use a better software than the
homegrown thing I was using before. So I started looking into Linotype
again and decided that it is in need of quite a lar
ly continues to do so), gathering experience
with it and helping testing and further stabilizing is not the worst
thing to do IMO :-)
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-
w long until Andreas returns from vacation? :-)
Michi
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
keep going forever ;-)
The existing code base might not satisfy everybody, but at least it's
something
concrete to start with, even if it will be totally modified resp.
refactored in the end.
Michi
--
Guido Casper
-
S&N AG, Competen
d on a standard is too
ambitious. Leaving out some more complex constructs decreases usability.
It might be an option to choose a (proper) subset of a standard with
which a large percentage (definitely more than 80%. Having to resort to
another solution in one of four situations is not accepta
PI, but like I said
previously, having done so, be prepared to throw it out
Yes. I take that as a precondition for any scratchpad code (if not for
any code within the Cocoon CVS). However there doesn't seem to be much
interest in that code anyway. So I rather wait for other s
e.
Then maybe this would give us probably the remaining 20% for those who
need the whole thing?
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Hunsberger, Peter wrote:
Guido Casper <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
Guido Casper <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may s
Hunsberger, Peter wrote:
Guido Casper <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
However, on the
Cocoon side it's not the GUI I'm worried about, it's the underlying
engine. There may still be value in one of the other
projects, but I'm
personally after v
people on this list being able to integrate Rhino
equally easily), just want to show how flexible the state pattern is.
And basically that's a major point, it gives you a very flexible
approach while allowing you to continue working with what you are
already familiar with.
WDYT?
Guido
tting how that might work :-)
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
Torsten Curdt wrote:
Since we are currently in the middle of cleaning
up and focussing on *the* one form framework I
like to propose and get rid of precept.
*snief*
I guess it's more or less dead code now and
it's an unecessary choice we should get rid of
IMO. I doubt anyone is using it so we won
Hunsberger, Peter wrote:
You can call it whatever you want but a "state" in a FSM and a
"continuation" in a script are exactly the same thing, they need to
contain the same amount of data to be able to resort the execution.
The problems in replicating one across containers will be the same
prob
Hunsberger, Peter wrote:
A good implementation of work flow handling for Cocoon could be the most
important piece of missing capability that can be added. For the most
part good work flow engines are expensive proprietary pieces of
software. If a generalized, open source, document handling framew
Torsten Curdt wrote:
Shouldn't one be able to keep the old block
and use 2.1.5-dev? ...as an interim solution?
Yes, I can live with that. But I think it's not a good sign for our
users. A user should have a chance to migrate while using a released
version.
Guido
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Reinhard Pötz wrote:
...
Sorry for this. I thought there was no need for the old block but if
somebody needs it we can revert the removal.
Oh yes, *please*, *please*, because this instantly breaks all
applications that use woody and the latest C
Hunsberger, Peter wrote:
Guido Casper <[EMAIL PROTECTED]> writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
transparent; the first time I wrote GUI modeling too
tool being both.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
up with a full featured workflow engine still simple
to use from Cocoon for simple use cases, I would immediately use that.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5
Gianugo Rabellino wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
...
I'm afraid it's not that simple. Your workflow allows only for a
linear flow, where you have only one way to go in the opposite
directions (back and forth). But quite
Guido Casper wrote:
The major drawback currently is that my AbstractState has to know
about all the other states (to prevent each State class having to
know about all the other states) and (when adding NewState) has to be
updated with: allowEnterNewState(doc, user) {return false;}
I have the
rying a comment.
I think the repository is implementation specific and shouldn't be part
of the interface.
Agreed.
Guido
The user might also be regarded as an aspect of the
manager's state but I am less sure of that.
--
Unico
--
Guido Casper
Gianugo Rabellino wrote:
Guido Casper wrote:
Interesting. would you like to share that with us? I think it would
be avery good exercise to see the two approaches one beside the other.
I don't have interest in generating my complete workflow logic out of
a UML diagramm or a XML fi
Stefano Mazzocchi wrote:
Guido Casper wrote:
Stefano Mazzocchi wrote:
If FSM work bad for flow, why would they work any better for workflow?
After thinking again about ways to use continuations with workflow I
came to the conclusion this might well be possible. But it looks awkward
to me
while workflow logic looks like an everlasting
loop of simple conditional logic with potentially lots of branches (the
user "actively triggers" the workflow).
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-
ht a lot about it) but I couldn't think of how
continuations make my life easier. Maybe that is because I don't think
about workflow as being instances of something (but this seemed to go
along with Stefano's thoughts). Now I'm not sure about that anymore ...
Guido
--
Gregor J. Rothfuss wrote:
hi,
the lenya community has developed a lightweight workflow that we thought
would make more sense as a cocoon block, especially given that other cms
built on cocoon have shown interest in using it (hi arje :). i split out
the generic part and made it into a (unstable)
Steve Krulewitz wrote:
I agree that more sophisticated input handing would make general web
applications much easier to write in Cocoon... here are some more random
thoughts on the subject:
Input can come from many sources:
- http query string
- http post stream
- http cookie
- user session obj
Alan wrote:
What do you mean by strongly typed? Are we discussiong form posts
here?
Yes, form posts being the use case at hand, but there are other ways
input may be provided. Quoting Daniel:
Besides using request parameters and "structured" request parameters as
user input. XML is used for
1 - 100 of 180 matches
Mail list logo
