Usercase Framework versus sitemap?

[Torsten Schlabach <ts...@apache.org>]

Dear all,

J. Wolfgang and myself have been working together today on editor
integration in general and on improving the BXE integration in particular.
We've already checked in a fix to the problem that BXE could not save
properly.

Now in a next step we though we'd replace edit-document.js with a usecase
written in Java. But this was not as easy as it looked like in the first
place. We found that we arrived at some design decisions that we cannot
and should not take without prior discussion.

The edit-document.js is not there for BXE alone, but it is shared by all
editors today (Kupu, BXE, One Form Editor, ...). It is in fact a contract
for writing to a Lenya document using a HTTP PUT operation. In other
words; this is sort of a WebDAV server implementation ... though we're not
sure if the PROPFIND stuff would be somewhere, but let's leave that aside.

A specific problem we ran into was that BXE only knows one URI (specified
by the BX_xmlfile parameter) that it will use both to GET the document
that shall be edited as well as to PUT the modified document.

In other words, we found that we cannot have a request with the same URI
handled by a publication specific sitemap fragment in case it's a GET and
by a Java usecase in case it's a PUT.

We moved away from doing the saving by pure means of sitemap components
(SourceWritingTransformer), so we probably don't want to go back there. Do
we?

But on the other hand, do we want to implement a GET operation that will
deliver the raw document as input for an editor in a Java usecase? Won't
we loose the flexibility of the sitemap that way?

Can a usecase (that is matched by the registred usecase matcher because it
is registered) yield control back to the sitemap? If yes, how? Or would be
it possible / an option / a good idea to modify the registered usecase
matcher in a way that a usecase can register itself only for specific HTTP
methods? In that case, a GET and PUT could be handles independently of
each other.

I hope the original dilemma becomes clear. If not, please ask Wolfgang or
me for clarification!

WDYT?

Regards,
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

[Andreas Hartmann <an...@apache.org>]

Torsten Schlabach wrote:
>>actions are the worst of both worlds. they clutter up the sitemap with
>>some logic, and some logic in the action itself.
> 
> 
> Why do you think so? To me if I read
> 
> <map:act type="language-exists">
> 
> or
> 
> <map:act type="reserved-checkin">
> 
> this is a good separation of layers to me.

In case (a) (language-exists) I agree, because the language-exists
action is a means to use the Lenya API in a presentation context.
In case (b) I disagree, because the "reserved checkin" action is
a means to use an internal component from sitemap-based logic.


> The sitemap author (who typically has a differnt skillset than the Java
> developer!) can see in one line what's happening without having to care
> about the implementation. And it's easy to say: I don't want RC, so I
> remove this. If this was in Java, it would be a complete re-build.

Hmmmm, I strongly disagree. If disabling revision control means to
remove all <map:act type="reversed-checkin"> from the sitemaps, we
did a quite bad job :)

IMO things like this should be handled beyond the API, transparently
to the integrator. We have to decide if we want to make RC optional. If it
is optional, the integrator should be able to configure it. If it is
mandatory, the integrator should *not* be able to switch it of without
understanding the implementation. Otherwise, we create a huge source
of trouble ...


>>i am very sceptical about such claims because i have to maintain an
>>application where someone wrote a 4000 line sitemaps with actions
>>calling actions..
> 
> 
> Well, you can abuse anything! But let me explain a bit more where I am
> coming from:
> 
> One of our goals for 1.4 is to lower the entry barrier.
> 
> IMO this is certainly not achieved if we need to raise the average Lenya
> implementor's profile (not developer's profile) from
> 
> - XML + XSLT
> - Cocoon
> - JavaScript / JXTemplates
> 
> to
> 
> - XML + XSLT
> - Cocoon
> - JavaScript / JXTemplates
> - Java + Avalon
> (IMO, without experience in Avalon the Lenya Java layer reads like
> Chineese even to someone who knows Java as such)

I think it is rather achieved by moving the integrator's profile from

- understanding Cocoon (Sitemap, XSPs)

- understanding Lenya's home-grown concepts and implementation

to

- understanding Lenya's contracts and configuration options which
   are based on Cocoon configuration options as far as possible
   (cocoon.xconf)

- understanding Cocoon for more detailed customization

Keep simple things simple, complex things possible.
Changing sitemaps to disable RC is IMO somewhere in between.


> Put yourself in the shoes of a Cocoon user who like Cocoon and therefore
> considers Lenya as a CMS. You should be able to read the sitemaps
> (probably with some guidance, such as the document I just started last
> night - ok, it's only a start) and get an idea how it works. And you need
> this understanding to customize it to your needs. I don't think it's a
> relistic goal for 1.4 to take the CMS UI to a point where you don't need
> an understanding of what's going on under the hood to really build a real
> world site. (I said: build - not edit one page in it.)
> 
> WDTOTATI? (What to the others think about this issue?)

I think we should

- provide a well-defined and well-documented set of components to control the
   page presentation (PageEnvelopeModule, LanguageExistsAction, ...)

   (IMO we do a quite good job here in 1.2)

- provide a high-level API to support the implementation of custom CMS
   functionality (DocumentManager, WorkflowManager)

   (this improves in 1.4)

- provide configuration options where this makes sense (switch RC on/off,
   configure the workflow)


-- Andreas





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

["Gregor J. Rothfuss" <gr...@apache.org>]

Torsten Schlabach wrote:

> The sitemap author (who typically has a differnt skillset than the Java
> developer!) can see in one line what's happening without having to care
> about the implementation. And it's easy to say: I don't want RC, so I
> remove this. If this was in Java, it would be a complete re-build.

no. whether a resource type has rc or not could just as well be a 
configuration option in doctypes.xconf

> IMO this is certainly not achieved if we need to raise the average Lenya
> implementor's profile (not developer's profile) from
> 
> - XML + XSLT
> - Cocoon
> - JavaScript / JXTemplates
> 
> to
> 
> - XML + XSLT
> - Cocoon
> - JavaScript / JXTemplates
> - Java + Avalon

i agree with that part, but to me that does not mean we have to keep old 
technologies that have shown themselves to have many problems, such as 
actions.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

[Torsten Schlabach <ts...@apache.org>]

> actions are the worst of both worlds. they clutter up the sitemap with
> some logic, and some logic in the action itself.

Why do you think so? To me if I read

<map:act type="language-exists">

or

<map:act type="reserved-checkin">

this is a good separation of layers to me.

The sitemap author (who typically has a differnt skillset than the Java
developer!) can see in one line what's happening without having to care
about the implementation. And it's easy to say: I don't want RC, so I
remove this. If this was in Java, it would be a complete re-build.

> i am very sceptical about such claims because i have to maintain an
> application where someone wrote a 4000 line sitemaps with actions
> calling actions..

Well, you can abuse anything! But let me explain a bit more where I am
coming from:

One of our goals for 1.4 is to lower the entry barrier.

IMO this is certainly not achieved if we need to raise the average Lenya
implementor's profile (not developer's profile) from

- XML + XSLT
- Cocoon
- JavaScript / JXTemplates

to

- XML + XSLT
- Cocoon
- JavaScript / JXTemplates
- Java + Avalon
(IMO, without experience in Avalon the Lenya Java layer reads like
Chineese even to someone who knows Java as such)

Put yourself in the shoes of a Cocoon user who like Cocoon and therefore
considers Lenya as a CMS. You should be able to read the sitemaps
(probably with some guidance, such as the document I just started last
night - ok, it's only a start) and get an idea how it works. And you need
this understanding to customize it to your needs. I don't think it's a
relistic goal for 1.4 to take the CMS UI to a point where you don't need
an understanding of what's going on under the hood to really build a real
world site. (I said: build - not edit one page in it.)

WDTOTATI? (What to the others think about this issue?)

Regards,
Torsten

> Torsten Schlabach wrote:
>
>>>an additional problem are the rc actions. they need to be replaced by
>>>appropriate helpers that can be invoked from use cases.
>>
>> This is what I meant with "discussing design decisions":
>>
>> Do we want to move *all* logic from sitemaps to Java?
>
> actions are the worst of both worlds. they clutter up the sitemap with
> some logic, and some logic in the action itself.
>
>> I could imagine someone standing up and arguing, that the sitemap
>> provides
>> nice loose coupling of Lenya components and you may want to set up a
>> publication without RC for example. And this would be a valid view for
>> me.
>
> true, but that could just as well be handled in the usecase itself, no?
>
>> I am rather thinking the other way round: Do we need a usecase action
>> that
>> will allow us to call a specific Java usecase from the sitemap? I think
>> currently we just have a matcher which is placed very high in food
>> chain.
>> As soon as there is a Java usecase registered that matches the
>> lenya.usecase request parameter the sitemap banches into Java and you're
>> there. We have't found a way for the usecase to decide: I don't want to
>> handle this request myself but I want to give this back to the sitemap.
>> Do
>> you understand what I mean?
>
> i see your point about the GET / PUT
>
>> If there was such a mechanism, the bxe Java usecase could easily have a
>> look at the request method and decide that if it's a GET, he's not in
>> charge.
>
> or is in charge, and just does a sendPage with the xml of the page in
> the GET case, and a save & redirect in the PUT case, no?
>
>> As much as I am against abusing the sitemap as a programming language -
>> I
>> think taking it to a point where everything is Java and the good stuff
>> from Cocoon (sitemaps) is not used any more would we as wrong.
>
> we keep using it by calling pipelines from the use case. they do not
> have to necessarily be jx pipelines, either.
>
>> Hasn't the sitemap proofed to be a good glue that weaves the
>> specialized,
>> independent and autonomous Java components together in a quite flexible
>> way?
>
> i am very sceptical about such claims because i have to maintain an
> application where someone wrote a 4000 line sitemaps with actions
> calling actions..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

["Gregor J. Rothfuss" <gr...@apache.org>]

Torsten Schlabach wrote:

>>an additional problem are the rc actions. they need to be replaced by
>>appropriate helpers that can be invoked from use cases.
> 
> This is what I meant with "discussing design decisions":
> 
> Do we want to move *all* logic from sitemaps to Java?

actions are the worst of both worlds. they clutter up the sitemap with 
some logic, and some logic in the action itself.

> I could imagine someone standing up and arguing, that the sitemap provides
> nice loose coupling of Lenya components and you may want to set up a
> publication without RC for example. And this would be a valid view for me.

true, but that could just as well be handled in the usecase itself, no?

> I am rather thinking the other way round: Do we need a usecase action that
> will allow us to call a specific Java usecase from the sitemap? I think
> currently we just have a matcher which is placed very high in food chain.
> As soon as there is a Java usecase registered that matches the
> lenya.usecase request parameter the sitemap banches into Java and you're
> there. We have't found a way for the usecase to decide: I don't want to
> handle this request myself but I want to give this back to the sitemap. Do
> you understand what I mean?

i see your point about the GET / PUT

> If there was such a mechanism, the bxe Java usecase could easily have a
> look at the request method and decide that if it's a GET, he's not in
> charge.

or is in charge, and just does a sendPage with the xml of the page in 
the GET case, and a save & redirect in the PUT case, no?

> As much as I am against abusing the sitemap as a programming language - I
> think taking it to a point where everything is Java and the good stuff
> from Cocoon (sitemaps) is not used any more would we as wrong.

we keep using it by calling pipelines from the use case. they do not 
have to necessarily be jx pipelines, either.

> Hasn't the sitemap proofed to be a good glue that weaves the specialized,
> independent and autonomous Java components together in a quite flexible
> way?

i am very sceptical about such claims because i have to maintain an 
application where someone wrote a 4000 line sitemaps with actions 
calling actions..

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

[Torsten Schlabach <ts...@apache.org>]

Gregor,

> please consider to centralize the bxe usecase while you are at it.

We do!

> an additional problem are the rc actions. they need to be replaced by
> appropriate helpers that can be invoked from use cases.

This is what I meant with "discussing design decisions":

Do we want to move *all* logic from sitemaps to Java?
I could imagine someone standing up and arguing, that the sitemap provides
nice loose coupling of Lenya components and you may want to set up a
publication without RC for example. And this would be a valid view for me.

I am rather thinking the other way round: Do we need a usecase action that
will allow us to call a specific Java usecase from the sitemap? I think
currently we just have a matcher which is placed very high in food chain.
As soon as there is a Java usecase registered that matches the
lenya.usecase request parameter the sitemap banches into Java and you're
there. We have't found a way for the usecase to decide: I don't want to
handle this request myself but I want to give this back to the sitemap. Do
you understand what I mean?

If there was such a mechanism, the bxe Java usecase could easily have a
look at the request method and decide that if it's a GET, he's not in
charge.

As much as I am against abusing the sitemap as a programming language - I
think taking it to a point where everything is Java and the good stuff
from Cocoon (sitemaps) is not used any more would we as wrong.

Hasn't the sitemap proofed to be a good glue that weaves the specialized,
independent and autonomous Java components together in a quite flexible
way?

WDYT?

We'll continue some experiments ...

Regards,
Torsten

Regards,
Torsten

> Torsten Schlabach wrote:
>
>> J. Wolfgang and myself have been working together today on editor
>> integration in general and on improving the BXE integration in
>> particular.
>> We've already checked in a fix to the problem that BXE could not save
>> properly.
>
> please consider to centralize the bxe usecase while you are at it.
>
>> Now in a next step we though we'd replace edit-document.js with a
>> usecase
>> written in Java. But this was not as easy as it looked like in the first
>> place. We found that we arrived at some design decisions that we cannot
>> and should not take without prior discussion.
>
> an additional problem are the rc actions. they need to be replaced by
> appropriate helpers that can be invoked from use cases.
>
>> The edit-document.js is not there for BXE alone, but it is shared by all
>> editors today (Kupu, BXE, One Form Editor, ...). It is in fact a
>> contract
>> for writing to a Lenya document using a HTTP PUT operation. In other
>> words; this is sort of a WebDAV server implementation ... though we're
>> not
>> sure if the PROPFIND stuff would be somewhere, but let's leave that
>> aside.
>>
>> A specific problem we ran into was that BXE only knows one URI
>> (specified
>> by the BX_xmlfile parameter) that it will use both to GET the document
>> that shall be edited as well as to PUT the modified document.
>
> maybe ask for bxe to support two different urls?
>
>> In other words, we found that we cannot have a request with the same URI
>> handled by a publication specific sitemap fragment in case it's a GET
>> and
>> by a Java usecase in case it's a PUT.
>>
>> We moved away from doing the saving by pure means of sitemap components
>> (SourceWritingTransformer), so we probably don't want to go back there.
>> Do
>> we?
>
> no. the source writing transformer always struck me as a side effect.
>
>> But on the other hand, do we want to implement a GET operation that will
>> deliver the raw document as input for an editor in a Java usecase? Won't
>> we loose the flexibility of the sitemap that way?
>>
>> Can a usecase (that is matched by the registred usecase matcher because
>> it
>> is registered) yield control back to the sitemap? If yes, how? Or would
>> be
>> it possible / an option / a good idea to modify the registered usecase
>> matcher in a way that a usecase can register itself only for specific
>> HTTP
>> methods? In that case, a GET and PUT could be handles independently of
>> each other.
>
> it seems to me you could load the xml in the use case and then use a jx
> view to display it to the editor.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Usercase Framework versus sitemap?

["Gregor J. Rothfuss" <gr...@apache.org>]

Torsten Schlabach wrote:

> J. Wolfgang and myself have been working together today on editor
> integration in general and on improving the BXE integration in particular.
> We've already checked in a fix to the problem that BXE could not save
> properly.

please consider to centralize the bxe usecase while you are at it.

> Now in a next step we though we'd replace edit-document.js with a usecase
> written in Java. But this was not as easy as it looked like in the first
> place. We found that we arrived at some design decisions that we cannot
> and should not take without prior discussion.

an additional problem are the rc actions. they need to be replaced by 
appropriate helpers that can be invoked from use cases.

> The edit-document.js is not there for BXE alone, but it is shared by all
> editors today (Kupu, BXE, One Form Editor, ...). It is in fact a contract
> for writing to a Lenya document using a HTTP PUT operation. In other
> words; this is sort of a WebDAV server implementation ... though we're not
> sure if the PROPFIND stuff would be somewhere, but let's leave that aside.
> 
> A specific problem we ran into was that BXE only knows one URI (specified
> by the BX_xmlfile parameter) that it will use both to GET the document
> that shall be edited as well as to PUT the modified document.

maybe ask for bxe to support two different urls?

> In other words, we found that we cannot have a request with the same URI
> handled by a publication specific sitemap fragment in case it's a GET and
> by a Java usecase in case it's a PUT.
> 
> We moved away from doing the saving by pure means of sitemap components
> (SourceWritingTransformer), so we probably don't want to go back there. Do
> we?

no. the source writing transformer always struck me as a side effect.

> But on the other hand, do we want to implement a GET operation that will
> deliver the raw document as input for an editor in a Java usecase? Won't
> we loose the flexibility of the sitemap that way?
> 
> Can a usecase (that is matched by the registred usecase matcher because it
> is registered) yield control back to the sitemap? If yes, how? Or would be
> it possible / an option / a good idea to modify the registered usecase
> matcher in a way that a usecase can register itself only for specific HTTP
> methods? In that case, a GET and PUT could be handles independently of
> each other.

it seems to me you could load the xml in the use case and then use a jx 
view to display it to the editor.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org