Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

[Mark Lundquist <ml...@comcast.net>]

On Jun 22, 2005, at 9:23 AM, <so...@gmail.com> wrote:

> 1. "Views" is almost the worst name for what it does.  ("Puppies"
> might be better, but "Records" would be worse.)  Too much software
> uses "View" to mean a dynamically generated collection of records
> matching a SELECT statement.  Who decided it should be use for
> "Breakpoints"?  (OK.  It provides a different View of the pipeline,
> but "Breakpoint" would be a really obvious name.)

Really obviously wrong, IMHO :-) :-)

"Breakpoint" means, "stop dead in your tracks right here", i.e. freeze 
the execution state of something.  Concomitant to this is the wakeup of 
some out-of-band debugging monitor.  Not what a pipeline view does at 
all :-)

I didn't invent the term "view" for this, but I've never had any 
problem with this nomenclature (and I'm like "Mr. Anal Terminology 
Pants"), although I seem to remember that the Cocoon docs for this 
feature left a little to be desired :-)

my $.02 anyway :-)
Cheers,
—ml—


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

Re: Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

[so...@gmail.com]

On 6/24/05, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@gmail.com wrote:
> > I am wondering how best to implement document security.  My current
> > project handles it in XSL, but XSL should be for formatting, not
> > functionality.
> Hmmm, I wouldn't think that way round. The purpose shouldn't be
> defined by the technology, but rather the other way round. If you
> find XSLT suitable for your needs (although I agree that it seems
> strange to use them for security :) ), why shouldn't you use it?

Lenya is a platform; the more it provides, the less a developer needs
to code.  Because security was left out, I had to design and code
more.  That reduced my productivity.  It will also reduce the
productivity of all maintenance programmers, since they have more code
to maintain.

XSL is the last level before content. It contains the formatting.  The
formatting should be changable without chancing hurting security.

You can see my implementation at:
http://solprovider.com/lenya/security
With the modified menu.xsl, it is easy to hide menu items with XSL. 
It would require complicated XSL to block access to documents in
multiple sections.  And there is an "awareness" security flaw: an
unauthorized page returns different than a nonexistent page.  The
message in both cases should be:
"The page requested is missing, or you are not allowed to access it. 
You may need to login."
 
> > It could be handled in a Sitemap with something like
> > auth-protect, but that is where application functionality is defined;
> > a Usecase sitemap should not bypass the security because the author
> > forgot to copy something.  I think it needs to be built into the File
> > Generator.  That might be a Virtual Component (if they exist), but
> > hardcoding into the Java would be best.
> Maybe it could even be added in the repository layer, or at least
> in the RepositorySource (lenya:// protocol). Then it wouldn't be
> restricted to generation, but it would also apply to all other
> operations on a document.

Great!  
1. The protocol gets request for a file.
2. Checks if document exists.
3. Checks if security exists for file.
4. Checks if security passes for file.
5. Checks if language exists.
- language-version-does-not-exist flag:  (document-level, but falls up
path to publication flag)
E = Standard error
D = Fallback to default language (Standard error if it does not exist.)
C = Show language choice page (nolang.xml explained below.)
6. If any check fails, return publication error message.  If
publication does not have error message, use global error message.

If this is implemented, we can remove these from the Pipelines:
- language-exists Action
- document-does-not-exist Exception
because it would be impossible to create them.  Sitemaps become
slightly simpler; productivity increases (less code!)

Where is the security config?  sitetree.xml?

Where are the error messages?  An errors directory under config or content?
- error.xml (Standard Error for NotFound, NoLanguageVersion, and NotAuthorized)
- anonerr.xml (Standard Error suggesting login, fallback to error.xml)
- nolang.xml ("<i18n>The requested document is available for these
languages</i18n>: de, us, xx.")

solprovider

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

Re: Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

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

solprovider@gmail.com wrote:
> On 6/23/05, Andreas Hartmann <an...@apache.org> wrote:
> 
>>solprovider@gmail.com wrote:
>>
>>>Code reuse is better solved with Resources.
>>
>>Personally I don't like resources that much, especially because
>>they can't be shared between sitemaps.
>>Just FYI, maybe you're interested in this:
>>http://wiki.apache.org/cocoon/VirtualComponents
> 
> 
> Was that proposal implemented?

Carsten Ziegeler is working on it in the trunk:

cocoon/trunk/src/java/org/apache/cocoon/sitemap/impl/AbstractVirtualSitemapComponent.java

> We were discussing Views, which also cannot be shared between sitemaps.

Yes, you're right. But I've never seen views as a means for pipeline
reuse anyway ...

> Resources are good as subroutines or macro substitution.  It would be
> nice if they could be defined in a header file or alternate sitemap. 
> Then a single Resource could finish the processing of every document
> in every Sitemap.
> 
> That could also be implemented by making the HTML Serializer a Virtual
> Component to always:
> i18n Transform
> StripNamespaces
> HTML Serialize

Yes, that is a nice example.

> What exactly is inherited by Sitemaps?  Just Components: Generators,
> Serializers, Selectors, Readers, Actions and Pipes?  Views and
> Resources are not inherited.  Pipelines must specify how to jump. 
> Flow must return to the Sitemap that called it.
> 
> -- Almost-related topic:
> I am wondering how best to implement document security.  My current
> project handles it in XSL, but XSL should be for formatting, not
> functionality.

Hmmm, I wouldn't think that way round. The purpose shouldn't be
defined by the technology, but rather the other way round. If you
find XSLT suitable for your needs (although I agree that it seems
strange to use them for security :) ), why shouldn't you use it?

> It could be handled in a Sitemap with something like
> auth-protect, but that is where application functionality is defined;
> a Usecase sitemap should not bypass the security because the author
> forgot to copy something.  I think it needs to be built into the File
> Generator.  That might be a Virtual Component (if they exist), but
> hardcoding into the Java would be best.

Maybe it could even be added in the repository layer, or at least
in the RepositorySource (lenya:// protocol). Then it wouldn't be
restricted to generation, but it would also apply to all other
operations on a document.

-- Andreas


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

Re: Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

[so...@gmail.com]

On 6/23/05, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@gmail.com wrote:
> > Code reuse is better solved with Resources.
> Personally I don't like resources that much, especially because
> they can't be shared between sitemaps.
> Just FYI, maybe you're interested in this:
> http://wiki.apache.org/cocoon/VirtualComponents

Was that proposal implemented?

We were discussing Views, which also cannot be shared between sitemaps.

Resources are good as subroutines or macro substitution.  It would be
nice if they could be defined in a header file or alternate sitemap. 
Then a single Resource could finish the processing of every document
in every Sitemap.

That could also be implemented by making the HTML Serializer a Virtual
Component to always:
i18n Transform
StripNamespaces
HTML Serialize

What exactly is inherited by Sitemaps?  Just Components: Generators,
Serializers, Selectors, Readers, Actions and Pipes?  Views and
Resources are not inherited.  Pipelines must specify how to jump. 
Flow must return to the Sitemap that called it.

-- Almost-related topic:
I am wondering how best to implement document security.  My current
project handles it in XSL, but XSL should be for formatting, not
functionality.  It could be handled in a Sitemap with something like
auth-protect, but that is where application functionality is defined;
a Usecase sitemap should not bypass the security because the author
forgot to copy something.  I think it needs to be built into the File
Generator.  That might be a Virtual Component (if they exist), but
hardcoding into the Java would be best.

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

Re: Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

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

solprovider@gmail.com wrote:

[...]

> Code reuse is better solved with Resources.

Personally I don't like resources that much, especially because
they can't be shared between sitemaps.

Just FYI, maybe you're interested in this:
http://wiki.apache.org/cocoon/VirtualComponents

-- Andreas


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

Re: Pipeline "views" (was Re: Re[2]: Lenya/Lucene Search errors)

[so...@gmail.com]

On 6/22/05, Mark Lundquist <ml...@comcast.net> wrote:
> On Jun 22, 2005, at 9:23 AM, <so...@gmail.com> wrote:
> > 1. "Views" is almost the worst name for what it does.  ("Puppies"
> > might be better, but "Records" would be worse.)  Too much software
> > uses "View" to mean a dynamically generated collection of records
> > matching a SELECT statement.  Who decided it should be use for
> > "Breakpoints"?  (OK.  It provides a different View of the pipeline,
> > but "Breakpoint" would be a really obvious name.)
> 
> Really obviously wrong, IMHO :-) :-)
> 
> "Breakpoint" means, "stop dead in your tracks right here", i.e. freeze
> the execution state of something.  Concomitant to this is the wakeup of
> some out-of-band debugging monitor.  Not what a pipeline view does at
> all :-)
> 
> I didn't invent the term "view" for this, but I've never had any
> problem with this nomenclature (and I'm like "Mr. Anal Terminology
> Pants"), although I seem to remember that the Cocoon docs for this
> feature left a little to be desired :-)

I documented Views at:
http://solprovider.com/lenya/views

I really focused on their use for "stop dead in your tracks right
here" since that is the primary (and maybe only) use most people will
have for them.  I even gave reasons for that perspective.  I could not
think of a reason where using a View would be better than adding
another Pipeline.  Code reuse is better solved with Resources.

Criticism is very welcome.
solprovider

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