Felix Knecht napisał(a): > > > I think that following "convention over configuration" here is > > really good idea and most users will take this advice. It help > > newcomers to focus on actual work, and it will help block's > > ecosystem because standardized URI spaces facilitate block's > > cooperation. > > I don't see such a big benefit. E.g. If a user has an application > using some forms he still needs to take care in the sitemap which > matchers shall be exposed externally and which not (think e.g. about a > multi-page formular and you only want to expose the starting page). I agree that my proposal does not cover such case you have given as an example. The point is that it shouldn't. I think that most blocks that user is going to create will expose some resources and/or services to the outside world and I think all blocks should do this in similar way.
When you create block's specific functionality (forms, pages) it's obvious that you have to create block's specific pipelines. I do not call this into question. My proposal is only skeleton (archetype) for further tweaking (extending, stripping). > IMO it will be more confusing (and therefore it may by dangerous) > having some resources exposed/not exposed by default.The developer > must decide anyway how the pipeline shall be (internal/external). It's > not only a design but also a question of security. Actually, until you put something in resource/external directory nothing is really exposed. By default you have only provided a directory structure which can be filled according to your needs. I don't see this confusing as I cannot think about something more obvious than that resources under "resource/external"are accessible externally. To provide an example, I'm refactoring now Ajax and Forms blocks. They both have some resources that should be exposed to the browser (css and js files) and they both would be exposing some services. I'm going also to make as a service samples styling so cocoon-samples-style is going to expose some css files and actual service. I can give you more examples if you need... -- Grzegorz Kossakowski
