Re: Less is more... or less?

[Stefano Mazzocchi <st...@apache.org>]

Sylvain Wallez wrote:

> So less is less when you have more on the *same* object accessed 
> directly in Java.

Sylvain,

less is more when all the things that you removed were not helping, not 
always.

The "less is more" design approach is a process, not a solution.

Instead of putting everything in FOM and deprecate bad ideas later, we 
opted for a process where we start small and add thing incrementally.

It might result that we end up making FOM a java clone of the java APIs 
we provide. If the community requires so, great, wonderful.

The point is that it has been done with a process that made it appear 
why we needed that, instead of just cloning over.

This means: if you think there is something missing in FOM or has to 
change, ask for a vote to add it, at that point, you'll find resistance 
and people might suggest better ways to do what you had in mind, or not.

Doesn't matter the outcome, it's the community process that counts.

In *that* regard, less is always more.

-- 
Stefano.

Re: Less is more... or less?

[Antonio Gallardo <ag...@agssa.net>]

Sylvain Wallez dijo:
> An example: last week, a customer of mine (I do mentoring for them and
> they're not subscribed to users@) asked me "I get a "no such property or
> method" error when calling context.getRealPath() in my flowscript.
> Why?". I answered that this method isn't available in flowscript and
> provided a 10-lines workaround involving looking up the sourceresolver
> and resolving a "context://" URL.

Can you provide more info about this issue? We had the same problem some
weeks ago and solved in a total diferent approach. Maybe our solution can
help you too.

I remember the old discusions about why block some parts of the API. The
overall idea was to avoid abusing of flow (javascript) to write all the
code there.

But thinking about why flow exists: As a controller. I realize the
controller must be able to solve paths in order to delegate.

So I am +1 in reviewing what we have avaliable and what not in FOM.

Best Regards,

Antonio Gallardo.

Re: Less is more... or less?

[Sylvain Wallez <sy...@apache.org>]

Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>
>> So less is less when you have more on the *same* object accessed 
>> directly in Java.
>
>
> Sylvain,
>
> less is more when all the things that you removed were not helping, 
> not always.
>
> The "less is more" design approach is a process, not a solution.


Sure, and I totally agree with that. I should have reminded in my post 
the quote that's on my weblog: "perfection is achieved not when there's 
nothing more to add, but when there's nothing left to remove" (Antoine 
de Saint-Exupéry).

> Instead of putting everything in FOM and deprecate bad ideas later, we 
> opted for a process where we start small and add thing incrementally.


Yeah, but the question is what is the FOM? Is it the objects that are 
made available, or the APIs on these objects? I know your answer: 
"both". But why do we have *two* different APIs in Cocoon for the exact 
same object, one being a subset of the other? This is really confusing 
to users.

An example: last week, a customer of mine (I do mentoring for them and 
they're not subscribed to users@) asked me "I get a "no such property or 
method" error when calling context.getRealPath() in my flowscript. 
Why?". I answered that this method isn't available in flowscript and 
provided a 10-lines workaround involving looking up the sourceresolver 
and resolving a "context://" URL.

Sure I could have started a vote to add getRealPath() to the FOM. But 
the customer needed it right now, and not in 2.1.5, and the 
workaround... well, just works even if ugly and slower. But it is a 
workaround.

> It might result that we end up making FOM a java clone of the java 
> APIs we provide. If the community requires so, great, wonderful.


That's where I see a limitation of the community dynamics and a proof 
that this API reduction is a bad thing, as it's faster to provide a 
workaround using a Java class and Cocoon's official APIs than discuss 
and vote some changes that will be available in the next release.

Also, the fact that the workaround uses the official Java APIs (and not 
clear violations of the public contract like 
CocoonComponentManager.getCurrentEnvironment()) clearly shows IMO that 
constraining the API of objects exposed by the FOM is useless.

> The point is that it has been done with a process that made it appear 
> why we needed that, instead of just cloning over.
>
> This means: if you think there is something missing in FOM or has to 
> change, ask for a vote to add it, at that point, you'll find 
> resistance and people might suggest better ways to do what you had in 
> mind, or not.
>
> Doesn't matter the outcome, it's the community process that counts.


Ok. I'll check what has been hidden from the environment API and start a 
vote on this. I do agree with the fact that not all objects should be 
exposed (although most of them actually are), but not with the reduction 
of the API.

Ah, and what about the FOM if/when we'll have a Java version of 
flowscript? Will we have a FOMRequest Java interface that will be subset 
of Request? That sounds totally silly...

> In *that* regard, less is always more.


Yep. Less APIs in JS than in Java for the same object is more confusion ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }