Stefano Mazzocchi wrote:
<rant>
I believe that sources have strongly polluted the design of the cocoon sitemap by making generators obsolete
I even heard people mentioning things like a xquery: source where you would encode the xquery in your URI. This has to end.
Sources *are* useful, don't get me wrong, but they are easy to abuse because they represent higher abstractions and like pretty murmaids seduce you with their portability and reusability.
They good sources are the one that you can think about putting in your browser address textbox: file: http: https: ftp: cocoon: everytime there is a src="" attribute you need to get the source. it's a transport mechanism, it indicates *how* you get those bits to you... it should not be doing anything more than this.
The SourceRepository that Gianugo wrote shows pretty evidently how you can abuse this to a point where it doesn't even make sense anymore and it's totally useless.
Oh well, thanks so much... :-)
:-)
I must confess I'm not with you this time. I'm convinced that sources are one of the strongest features of Cocoon, and I don't quite give a damn about them having obsoleted a few generators (not _all_ of them though: the idea is virtualizing a transport - only generators that need to do more than just bytestream->SAX conversion have been obsoleted. Keep in mind that sources are a transport virtualization *AND* an API (and a good one IMO, where composition shows its power and flexibility).
Well, Sources and Generators do overlap in functionality but not completely. What I want is to come up with a design pattern that suggests usage of them and avoid abuse.
the repository *is* the place where you save, it shouldn't be *you* to specify where and how to save it.
This is what Gianugo did with the SourceRepository and I *do* think it's terrible design. [no offense, of course, I appreciate the attempts, especially when they teach you where not to go]
No offense taken, exp. since you're the one to blame as well. :-)
Oh, yeah!
The SourceRepository was more or less a find&replace exercise over your original one which has exactly the same problem, only limited to a local file (you pass it an absolute path anyways, what changes in the SourceRepository is that you're passing a ModifiableSource altogether, which, agreed, is bad). What changes between the two is just
var home = "/some/path"
to
var home = "proto://host/some/path"
no big deal. :-)
yes, but the problem is that people started to abuse those source using the webdav protocol and this blurred the repository contract.
I found the partition of work - reading operations via Sources (which BTW is their original intention) and modifying operation via Repository - quite useful.
I doesn't think that we should delegate similar aspects into different code parts.
Agreed. We need a repository API and a generator that uses that API to connect to the repository and streams SAX events out of it.
I still don't see what is your problem with Sources. I can foresee some security issues since there might be an unexpected direct access instead than going just through the APIs, but this is something that might happen anyways and you protect yourself in other ways.
Oh, there is no security concern, is just a matter of forcing people to serialize the contract in one line! That I don't like!
And, speaking about disagreement between me and you, I really have a problem with your plan:
I think that flow changed the picture so much that we now have to rethink where those sitemap artifacts really still make sense or not.
And I mean:
1) actions (I guess everybody agrees on this now) 2) sources (getting there) 3) input/output modules (next target)
I have the impression that this agenda is going to break the most fundamental design of Cocoon: everything moved to flow breaks horribly the pyramid of contracts, impairs sitemap readability and overall makes maintaining complex applications a nightmare. The beauty of Cocoon is having everything under control in one file (or a set of files with a coherent layout/syntax) geared to non-necessarily overtechies. Everytime you move non-pure-controller functionality to flow, a black hole opens in your sitemap, and you're not under control anymore.
I noticed this in our last large projects and, well, you have to see to believe. It's incredibly easy to build tangled webs of pipelines calling flows calling pipelines calling flows, where sorting out what happens to a given request is a job for a very skilled developers who have to sort out what happens in a programming language with a procedural approach.
While I'm with you with actions (pure controller logic), I really have a problem with input/output modules disappearing and with sources being under trial. Whatever moves outside of the sitemap not pure controller logic is dead wrong, IMO.
This sitemap/flow thing is OT here, I'll follow up in Guido's RT.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
