date:20030701

RE: [woody] binding the forms to data

2003-07-01 Thread Nathaniel Alfred

 -Original Message-
 From: Marc Portier [mailto:[EMAIL PROTECTED]
 Sent: Dienstag, 1. Juli 2003 07:37
 To: [EMAIL PROTECTED]
 Subject: [woody] binding the forms to data

...

 The actual binding definition file could be filled with:
 bnd:field id=widget-name
 path=xpath expression into model /

I don't see the added value of putting the binding definition into
a separate file.  It should be inside the woody-definition file to
avoid yet another maintenance nightmare of joining two XML files by
an id. 

 Using JXPath there should be a fairly easy way to have this 
 binding work for a backend producing either javabeans or XML files.

 what do people think?

The possibility to define constant initial values in wd:datatype
is urgently needed.  To have an easy way to set it dynamically would
be really cool.

wd:field id=widget-name
  wd:datatype base=string
wd:initialconstant value/wd:initial
!-- or --
wd:initial path='constant value'/
!-- dynamic --
wd:initial path=xpath expression into model/
  /wd:datatype
/wd:field 

A general load/save binding specification in XML can get pretty
nasty for real-world examples with one-to-many and many-to-one 
mappings between external form and model attributes.

I'd say Woody should stick to the rule to have a simple solution
for simple problems and provide hooks for solving difficult problems
in Java.

Cheers, Alfred.

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.

Re: [woody] binding the forms to data

2003-07-01 Thread Marc Portier

Nathaniel Alfred wrote:
-Original Message-
From: Marc Portier [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 1. Juli 2003 07:37
To: [EMAIL PROTECTED]
Subject: [woody] binding the forms to data
...

The actual binding definition file could be filled with:
bnd:field id=widget-name
   path=xpath expression into model /

I don't see the added value of putting the binding definition into
a separate file.  It should be inside the woody-definition file to
avoid yet another maintenance nightmare of joining two XML files by
an id. 

mmm, the set of ids in the form-model are pretty much it's 
contract to the outside world

if you need to code getWidget(id).setValue(..)
then the nightmare becomes syncing the java code with the XML 
file... there is not that much that binding can do to prevent 
that IMHO?

sliding everythin in one file might result in the opposite of 
your own 'simplicity' baseline?  (see further)

might be me being too overly SoC concerned though...

Using JXPath there should be a fairly easy way to have this 
binding work for a backend producing either javabeans or XML files.

what do people think?

The possibility to define constant initial values in wd:datatype
is urgently needed.  To have an easy way to set it dynamically would
be really cool.

wd:field id=widget-name
  wd:datatype base=string
wd:initialconstant value/wd:initial
!-- or --
wd:initial path='constant value'/
!-- dynamic --
wd:initial path=xpath expression into model/
  /wd:datatype
/wd:field 

nice feature on the static side of things...

but, I think I am more ambitious on the dynamic side of things: 
I want the changed values to propagate back to the objectmodel.
(think editing XML documents for instance)

that is more then just 'initial' binding

A general load/save binding specification in XML can get pretty
nasty for real-world examples with one-to-many and many-to-one 
mappings between external form and model attributes.

yep, thought crossed my mond, although defining some 
straightforward 'actions' in the binding should do the trick

bnd:repeater ..
  bnd:action event=insert-row
bnd:insert-node...template to insert.../insert-node
bnd:set-attribute name=status value=updated /
other issues you see?

I'd say Woody should stick to the rule to have a simple solution
for simple problems and provide hooks for solving difficult problems
in Java.
that is probably the biggest argument for keeping this binding 
into separate files.

maybe you like it more if you look at it as
FormManager builds Forms
Bindingmanager build Bindings
the code applies the binding to the form

as such woody's form model remains as simple as you like
the present hook for the code 'setValue' just got a more 
declarative way of exploiting things

to be totally clear: binding should never be required to be able 
to use a woody form.

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java  XML Competence Support Center
Read my weblog at  http://radio.weblogs.com/0116284/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[FYI] Javascript 2.0 proposal

2003-07-01 Thread Nicola Ken Barozzi

Since we have put our bets on javascript, it may be inetresting to 
follow discussions about the new Javascript.

http://www.mozilla.org/js/language/js20/

The nice thing is that the discussions seem to point to a more 
Java/Python-esque language, that can only make us happy :-)

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Introduction Reinhard Pötz

2003-07-01 Thread David Crossley

Welcome Reinhard, and thanks for the overview of you and your
excellent ambitions.

Reinhard Pötz wrote:
snip/
 
 Apart from Cocoon I'm on the way to become a Certified Transactional 
 Analyst (this has nothing to do with IT as many people believe but
 more with psychology), ... snip/

Then you might also be interested in http://www.why-compete.org/
and Aleader for Situation Assessment. The Manual doc provides
background and the Empathy Index provides some examples.

--David

DO NOT REPLY [Bug 21213] New: - [PATCH] Paginator caches dynamic pagesheet rules

2003-07-01 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21213.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21213

[PATCH] Paginator caches dynamic pagesheet rules

   Summary: [PATCH] Paginator caches dynamic pagesheet rules
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When the pagesheet rules are served over the cocoon protocol, instead of a 
static file, the pagesheet definitions are cached from the first time they are 
used. This is my usecase:

map:transform src=cocoon:/pagesheets/searchmachine.xml type=paginate
map:parameter name=page value={request-param:page}/
/map:transform

The problem lies in the fact, that the cocoon protocol Source alway's gives 0 
for their lastModified date. These let the Paginator think that the pagesheet 
rules has never changed.

This patch enables the paginator to work correctly with this scenario.

DO NOT REPLY [Bug 21213] - [PATCH] Paginator caches dynamic pagesheet rules

2003-07-01 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21213.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21213

[PATCH] Paginator caches dynamic pagesheet rules





--- Additional Comments From [EMAIL PROTECTED]  2003-07-01 08:52 ---
Created an attachment (id=7036)
patch for Pagesheet.java

Re: Aspect-based pipelines and link view ( Re: Link view goodness)

2003-07-01 Thread Nicola Ken Barozzi

Upayavira wrote, On 30/06/2003 18.18:
Guys,

The link stuff is a cross-cutting concern. This thread has IMHO shown
how aspects can be easily added to the sitemap, and effectively used.
Let's see...
...
map:resource name=gather-links from-position=content
!-- Any required link munging --
map:transformer type=gather-links/
/map:resource
...
Seems like simply adding this capability to resources is nice. We
could similarly make a link-view that uses the same transformer and a
serializer. In this way it could also be compatible with the 3pass
method. Hmmm...
Ie, a Resource inserted in each pipeline after the 'content' label.
Rather AOP'ish.
Yup. As link gathering is a cross-cutting concern, it also makes sense
conceptually.
So you're saying, with a resource that has a 'from-position' attribute, that specifies
after which label it should be inserted? That makes sense. So you only have to have
the resource once per sitemap, rather than having to insert it into every pipeline.
Exactly.

As you say, it automatically gets inserted in each place where I would
have to put it manually.

So it's not part of the single pipelines, but it's a common aspect of
the system that gets applied.

For example, if I wanted to log all method exits, I could put by hand a
log() call in each method. Or I could factor out this aspect and specify
with a rule where it applies, like saying:

foreach(method.return){
log()
}
The important thing here is how I can tell the system about where to
apply that code. It's important that it can be explained as a common
rule, or else I'll be just moving the single log calls out of the
methods, with no gain.

Here, linking has to be applied to a *group* of pipelines, in a specific
*part* of them.
IE: for xml pipelines, where the content is done, insert this transformer.

But - what if the pipeline itself needs modifying to expose links from within PDFs for
example. The LinkGatheringTransformer I have coded has two modes, one where it
just hunts for href, src and xlink attributes, and the other that searches for attributes
in the http://apache.org/cocoon/link-gatherer/1.0 namespace (probably to be used
with a 'link' prefix). This latter kind is required for gathering links that don't conform to
the href, src or xlink conventions. Just auto-inserting a link gatherer wouldn't work in
this case.
It has to be possible to define when one or the other apply.
Examples of the two usages?
...
Now we say: when the view is triggered, start at a label
After it could be: when the view is triggered, start at position
Instead we need: when the position is met, check if it has to be
triggered.
Here is an example that uses this inverted AOPish system for views.

The following adds two aspects:
- an aspect gets called from every content position and gathers
links. - the other one gets called from every content position. If
the
request has a cocoon-view=links, then the links are serialized.

map:aspects
map:aspect type=from-label test=content
!-- Any required link munging --
map:transformer type=gather-links/
/map:aspect
map:aspect type=from-label test=content
map:action type=request-param
map:param name=cocoon-view value=link
map:serializer type=links/
/map:action
/map:aspect
/map:aspects
This would make it very easy to add security-based checks, logging, or
any other stuff.
map:aspects
map:aspect type=pipeline test=start
map:action type=check-security/
/map:aspect
map:aspect type=pipeline test=all
map:transformer type=logger/
/map:aspect
map:aspect type=error test=all
map:action type=notify-admin/
/map:aspect
/map:aspects
What do others think?
...
I'm afraid you left me completely behind there. I've not really yet understood what
AOP is, and your ideas go far further than my Cocoon implementation skills currently
allow.
It's quite easy once you go behind the words...

I'd quite like to find something that can be implemented reasonably short term, and
then explore these more far-reaching ideas as time passes (and as the size and
capacity of my brain increases).

Are you guys interested for the time being in a LinkGatheringTransformer as
described above? Or is there something not too far away that we can do now to
gather links?
- Upayavira sanity check System -
- please wait... -
- ... -
- control NicolaKen ...
- in progress...
*** ALERT ALERT ***
*** Highly volatile thoughts ***
*** ALERT ALERT ***
Ok, I got the message ;-)

Thanks for bringing me back to earth, I have the ?slight? ;-) tendency
of flying high.

Let's see what we need to resolve for this case.

We said that the current gatherer has the problem of being fixed.
We have seen that a transformer placed in the right place can be more
configurable.

So, the reasonable solution that comes from this is that if the
user-defined pipeline is caching links, those are used.
If not, Cocoon inserts a gatherer in the right position.

1 2 >

100 matches

Mail list logo