Thank you again for feedback; some comments though:
Upayavira wrote:
Dependencies between blocks are a relatively new thing - at the moment we've just dealt with it with comments in the blocks.properties file, which is not ideal, but better than not telling anyone at all.
yes, but unfortunately they are far from complete: since the last email I already had to restart the build twice because of not marked dependencies... this is really extremly awkward.
I agree it is awkward. If we can come up with a better way of 'annotating' the blocks.properties file, then I'm sure no-one will complain.
You probably perceive a resistance to helping to improve stuff like the build process, or to making binaries available. This, I believe, is because developers would rather concentrate on implementing real blocks, rather than putting effort into the current build process, which was _always_ seen as a temporary measure.
yes, I think you have established that, and I understand it.
Ok.
However, I have the impression, that the Cocoon developers, which are is very obviously a group of excellent developers, sometimes oversees the fact, that Cocoon is not longer a hacker tool, but there are thousands of "normal" users outside; and when you announce a new release, certain basic attributes should exists.
One is, that the build and installation is transparent even to non-Cocoon-contributors;
Cocoon isn't a simple thing to use. I think we have to accept that. And we do have a super block system in the pipeline. In the meantime, if we can come up with relatively simple changes to our existing setup, then, as I say, I think they'll be accepted.
I might not be the brightest of all Cocoon users, but you might assume that I am at least the "average dummy user", and I report the problems and issues, because I love the project; many others simply dump the idea to use Cocoon.
And I for one appreciate it!
cant you provide a set of 3-5 blocks.properties files at least, so that every user can choose from a set of working properties the best suited for the problem?
I've watched this, again, and again, and again. No two people can agree on what they need and what they don't. It is simply not possible to identify a few tailored blocks.properties, as there are just so many relevant combinations.
Sorry, to point this out again: this is the usual "guru-problem": not agreeing about a solution, because no suggested solution offers 100% quality (only 80% at best), and the result is an eternal discussion with a "no-solution" that has the quality of 20% (as of now). And 95% of Cocoon installations use the "full program" as in the current properties file. This was not intended, I believe.
That's how it was with 2.0. If some people can work out how to cut down within 2.1, then that's good, IMO.
At this point I have to say:
*please* -- for the sake of the normal user -- take a decision, and put 3-5 properties files into the release!! They can at least be a guidance for the unskilled ones. and the expert can configure as he does it right now.
What I propose (at least for now) is to improve the contents of the blocks.properties file so that an unskilled user can work out what they need to do.
E.g. If all you use is the basic Cocoon facilities (FileGenerator, XSLTTransformer, HTMLSerializer) then you can disable ALL blocks.
Use with CLI
Note: currently the CLI will not work with these blocks included: XXX, XXX, XXX
What do you think? Maybe you can suggest some other notes that would help within the blocks.properties file.
Regards, Upayavira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
