Need a new Forms Sample (and other improvements to forms)
Based on my experiences with CForms, I have to say that I am very
frustrated. Yet at this point we are committed. I think something
that would greatly reduce my frustrations as well as other potential
users is a full soup to nuts explanation of how to set up forms for
your existing application from scratch. Next, and possibly just as
important, how to use CForms to do tag management like del.ico.us and
Flickr. There should be three tracks depending on what you bind your
form to. I'm not the guy to do it because I am completely lost and I
can't seem to make heads or tails of where I am in the process or what
is going wrong.
Now, as to improvements to forms, there are some things that are
absolutely necessary in order to make use of CForms. First, is a
special type of sitemap. An extension, if you will, that automatically
adds the matchers necessary to resolve the _javascript_ resources instead
of relying on people to set that up themselves. It would also include
the declarations for the CForm specific
generators/selectors/serializers/transformers/etc.
Additionally, there are two ways to set up forms depending on whether
AJAX is enabled or not. Typically you have a generator followed by a
transformer. Why not make one forms generator that handles that for
you (i.e. auto-chains the necessary transformations right after the
source is generated ala JX script)? Also there is a transformation
followed by a choice of serializer. Again, why not have a forms
serializer that takes care of the final transformation and choice of
serializer for you?
It took me a week of trial and error to figure out why things were only
partially working on an upload form. I finally have it working, but
the AJAX enabled portion is not doing its job right. There is more
trial and error and I don't have another week to futz with it.
At this point, I'm going to have to give up on doing things the CForms
way and hack together something that is far less elegant but I know
will work. At least I will be able to report progress. I'm sharing
these observations in the hopes that we can avoid having more folks as
frustrated as me.
--
Berin Loritsch
Owner
Work:
571-215-7708
Email: [EMAIL PROTECTED]
IM:
[EMAIL PROTECTED] (MSN)
http://www.linkedin.com/in/bloritsch
D-Haven
20044 Great Falls
Forest Dr.
Great Falls, VA 22066
USA
See who we
know in common
Want a signature like
this?
[Fwd: CForms and Uploads?!?!]
--- Begin Message --- I am beyond frustrated with trying to adapt the CForms upload feature to our application. I have about two hours left for today, and I'd like to get it working, but if I can't I will resort to the traditional method of forms and actions. Please, if you have bandwidth to spare, contact me on MS Messenger: [EMAIL PROTECTED] I'm experiencing strange things. Once the initial form is displayed and sent to the server, whether everything is OK or not, it goes to the "success" scenario. Worse, the "success" scenario is a cocoon stack trace with a SAXException saying "No Cocoon Form found." Nothing I can see in my sitemap or flowscript suggests that that should happen, and yet here I am. --- End Message ---
How is the cocoon object model set up?
I submitted bug COCOON-1816 because the cocoon object model was not set up in a way that I expected. It cost hours of lost productivity only to find out I have to bounce my processing for a static page (with a couple variable pieces) through a flowscript just to access cocoon.request. To me that is an example of something that can be fixed to improve the perceived simplicity of the system. It seems unreasonable to require Flowscript first for a largely static page--nothing has to be set up, I just need to get a bit of information from the request object. I believe the cocoon object model is a great selling point--as long as it is set up consistently and available to all sitemap components without forcing one component to be executed before another. Not all problems require flowscript. Is the COM strictly tied to the flowscript engine? Is there any way we can safely and simply extract that out?
[jira] Created: (COCOON-1816) JEXL Does not support full cocoon object model on its own
JEXL Does not support full cocoon object model on its own - Key: COCOON-1816 URL: http://issues.apache.org/jira/browse/COCOON-1816 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.8 Reporter: Berin Loritsch Priority: Critical JEXL will not allow you to access cocoon.request or cocoon.session and company unless a flowscript performs a sendPage related request. This violates the principle of least surprise, and caused over four hours of productivity loss just trying to figure out why something that _should_ work wasn't. All the documentation suggests that I could access the full cocoon object model without any reference to flowscript. The cocoon object model should be set up in a way where it is accessible directly in JEXL as well as in the flowscript. In short, it should be set up properly as a core feature so that it is accessible and usable in a consistent way throughout the entire application. JEXL, Flowscript, or any other new technology that comes along. One component should not depend on another to set things up if you can't reasonably expect them to be completely coupled. In short, JEXL should be usable independantly from Flowscript. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Using a Java Object from XSLT
I have a Java object I am using to generate links. It would make my life easier if I could use it directly in my XSLT--even though it is created outside of the XSLT system. Is it as easy as passing it in as a parameter? Or is there some extra leg work necessary?
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Niklas Therning wrote: Carsten Ziegeler wrote: Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. Given the Avalon framework interfaces, we already have a log abstraction using the LogEnabled and Logger interfaces. Proper wrappers are also provided for Log4J and have been for years. There's no value add in introducing YALF (Yet Another Logging Facade). In the future when your components have no ties to Avalon, just use Log4J directly.
A new FAQ entry?
This is really a three pronged question: 1. Do we have a project FAQ? 2. Where is it? on daisy? 3. Should we put this as a new entry? Someone on the users list asked about problems scaling Cocoon--Tomcat was crashing with OutOfMemoryErrors even though plenty of RAM was made available using the -Xmx parameter. We pointed him to JVM and garbage collection as a possible culprit (as well as pool sizing). As it turns out, the JVM parameters were the issue. With proper tuning of the JVM (and an upgrade) they have been happily stable ever since. It didn't really have anything to do with pool sizing. The thing is that this issue is not a Cocoon issue, but a JVM configuration issue. Nevertheless it is not intuitive, and pointers to how to configure the JVM would help others in his situation.
Re: why user-roles?
Stefan Pietschmann wrote: What is the benefit of declaring custom roles in a user-role file outside cocoon.xconf, if you can do it together with the configuration inside cocoon.xconf? Is there any? I don't see the point … Stefan It helps with conciseness in the cocoon.xconf. For non-standard custom components, it's probably easier to do the generic xml setup. The Roles file makes it so the config file is a little bit friendlier to users.
Re: [VOTE] preliminary wrap-up
Jorg Heymans wrote: OK, so unless someone vetoes this the next few hours i will start shifting files about around 11pm CET today. It would be great if people could refrain from checking stuff into trunk/core from then onwards until i've finished. It will take a good few hours, i'll notify when it is done. also : should we make some sort of backup first or is everything fully reversible from the svn command line ? Just to be on the safe side ... Tag the trunk before you start, and then again afterwards. But to answer your question, yes everything is reversible from the svn command line.
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: URL interpretation ? SourceResolver and company It proved to be very valuable extension point I'm not negating that, however the way it is currently implemented makes it difficult to use at times. Again there are different ways of skinning this particular cat that would be more efficient. I do recall why we didn't try to use Java's own URL "component" framework. It really wasn't due to complexity of getting the URLStreamHandlers to communicate with Cocoon. It was due to the fact that some web containers like BEA WebLogic and IBM WebSphere preset the static instance of URLStreamHandlerFactory, making it impossible for us to override it. I don't recall if we tested extending where the URLStreamHandlers are located using the "|java.protocol.handler.pkgs" system property. The advantage of using Java's extension mechanism here is that we would be able to use our cocoon:// URLs inside of FOP and any other library that relies on URLs. If we don't rely on components for the core of Cocoon, then we have more flexibility on improving this point. | It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, "Simplicity is the ultimate sophistication". The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Right. Although just because something is an extension point does not mean it has to necessarily be a component.
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: Berin Loritsch wrote: Daniel Fagerstrom wrote: "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. URL interpretation ? SourceResolver and company Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, "Simplicity is the ultimate sophistication". The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here.
Re: GroupBasedProfileManager
Carsten Ziegeler wrote:
Ok, perhaps the code isn't that bad...now, both methods
(getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one
thread can enter them and therefore only one thread can change the
corresponding objects. At the end of the method, the map is returned and
this return value is then used for the current user profile.
So, if now another thread is entering the getGlobalBaseDatas method and
overwriting the copletBaseDatas.objects value, the first user is not
affected as he is working on his copy. At least this is how I think it
should work. WDYT?
Without looking at the code it sounds like what you have here is
something like this:
getGlobalDatas()
{
data = getGlobalBaseDatas()
doSomethingWith( data )
return data
}
If that is the case (i.e. getGlobalDatas always starts with a copy of
the base datas), then only the getGlobalBaseDatas should be
synchronized. That avoids two different threads synchronizing on the
same monitor because they are accessing different threads. It keeps the
length of holding the monitor at its minimum.
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Berin Loritsch skrev: ... Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. I don't know enough about Photoshop to be able to follow your analogy. Are you talking about extension points and plugins as in Eclipse or are you talking about some other level of granularity? Pretty much. ... The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more. "Decomponentization" could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) URL interpretation Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
[RT] The Real Component Simplification
Much has been talked about in regards to the component infrastructure. That's a good thing, but after years of component based design, and getting back to the roots of just plain old object oriented design, I have to question why everything needs to be a component. Using good OOD, we can create a solid and robust core--devoid of any configuration settings--and only provide extension points. I.e. plugins. Here's my reasoning, component based design (CBD) is a restricted form of OOD with some initialization magic thrown in. The key weakness in a CBD system is that everything is a moving part. While the flexibility is a strength, the resultant instability is a weakness. It is much easier to design for error tracking using plain old OOD than it is in a system where you don't manage the objects you are using. There are several OO tricks we can't use, or are not using. At the same time, we have some aspects of our system that need to be extended with user provided functionality. Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. There are three areas where we can use the plugin behavior: pipeline components (generator, serializer, transformer, reader), processor (sitemap, rails like router, blocks), and inter-block communication. Everything else should be part of the core. For example, the core does not need to worry about how to stylize the content of your blocks. That is a function of inter-block communication. The core only needs to worry about how to work the different things together. The core does not need to worry about database connections, only how Cocoon extensions relate to the environment. These should be very simple contracts. No moving parts, no configuration for configuration's sake. No need for reams of XML config files. Java 1.4 provided some nice alternatives to dealing with configurations. One notable example would be the Java Preferences API. I have a nice utility that abstracts away the Preferences API vs. a Properties file, and gives you a POJO interface for it. That will also make it easier to create standalone configuration apps using the rock solid JGoodies APIs. Oh, not to mention that my utility also allows you to obfuscate configuration entries like database username and password. The point is, that there are other approaches to configuration. Those approaches are better than XML config files for two reasons: processing the configurations is less complicated, and they are easily managed. The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more.
Re: [RT] Simplifying component handling
Torsten Curdt wrote: On 30.12.2005, at 20:21, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Gianugo Rabellino wrote: I'm definitely not a fan of constructor injection, exp. when we consider how (way too) often we resorted to inheritance in Cocoon components. Now, while interface injection is clearly out of fashion, sticking with Avalon/Excalibur also means that it would be difficult to get around the container (e.g., how do you release components with your approach? I assume Excalibur still kinda needs that). Yes, Excalibur still needs it - but it's easy. Bascially, you "emulate" the service() method on construction of the object and then you "emulate" the dispose method when destroying the object. Everything our ecm++ needs to know is there. As I said, I've done this in Fortress and we can use that code in ecm++ as well. And we could implement setter injection with some kind of auto wiring as well. It's not really that harder. But using setters again requires to code more than using a constructor. I'm with Gianugo on this one - I'd better have setter injection instead of constructor injection. Maybe this is becoming a bit OT but could you guys give some reasons why? I personally prefer contructor injection over setter injection because of the clear contract. As soon as the object is instantiated it can be used. With setter injection you have to have some weird behind the scenes object life-cycle. Well, personal preferences aside, there are pros and cons in any situation. First, any component that is able to be accessed is fully instantiated. Nothing more needs to be done. Setter injection vs. Constructor injection doesn't change a thing here. Both styles of code encorage different coding conventions. Setter Injection --- Familiar JavaBean style interface, natural to many Java developers, and easy to use introspection based tools. Encorages failsafe design so that almost all components are optional. In short, the absense of other components cause the bean to work with diminished capacity. An example is the DataSource object from the SQL package. In fact, that component would work out of the box in this type of environment. Constructor Injection - Very robust design, less familiar to many Java developers, but natural enough. Encourages tight encapsulation and failfast design so that almost all components are required. In short, the absense of other components can cause the component to crash. Examples include just about any unmodifiable POJO object. Spring is the XML laden container of choice for Setter Injection while Pico is the code it yourself container of choice for Constructor Injection. My personal preference would be for Pico primarily because it is not nearly so XML heavy. Also note that Pico can work with setter injection as well as constructor injection. My Java5 Dojo container works with Setter injection out of the box, and can easily be extended for constructor injection. Through the "Multi-Dojo" wrapper, it could have components designed for either style of development work seamlessly with each other. Even if you don't use it, you might take a look at the code. It's pretty straight-forward and a simple design.
Re: [RT] Simplifying component handling
Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
This is not the "safe" assumption, and can cause unexpected side-effects
in user's code. This is not a 2.x change.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
+1 for generalizing the factory pattern. Cocoon spends way too much
time in checking Avalon's lifecycle interfaces and parsing
configuration objects.
Well, a better pool like the MPool package at D-Haven will help. MPool
is the managed pool that will shrink pool sizes at a slower rate,
removing the need to think about pool sizes in general (i.e. no
deferring back to factory method).
The big thing about Avalon based components is the startup time due to
the configuration element parsing, etc.
Now, I will say that getting rid of component pooling will require a
major overhaul of the Cocoon internals.
My final idea is to use even more magic (but it might be too much
magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
"component_" are setup using some injection mechanism - or perhaps using
annotations?
Hmm...
- how do you unit test Cocoon without the container? By subclassing to
access the protected fields?
- we can't strongly enforce the contract of subclasses by making some
fields private.
- the naming convention weakens the strong typing of Java. What if you
write "conponent_A"? Chasing the NPE won't be easy...
Danger Will Robinson!
In addition to the reasons listed by Sylvain, you are deviating far into
left field from what the average Java developer is used to.
Now, in the end I really want to write less code :)
Use Ruby :-P
Seriously, I agree that writing less code is good, but not at the
price of too black magic implying weaker contracts.
Agreed. To achieve the goal of less code would require major overhauls
of the entire system.
Re: Cocoon hang in excalibur-pool
Vadim Gritsenko wrote: Ralph Goers wrote: OK. I'm wondering if the real problem is simply that the getDocument method is completely synchronized? It's *good*. You don't really want several threads trying to load *same* document. It's not perfect though. I see that XMLFileModule, when used in conjunction with cocoon:// protocol, might be a bit ... inefficient. Usage of DelayedValidity is prescribed here. Do you want to make a stab at implementing delay: protocol? :) Does the cocoon:// URL call a pipeline you are using in another segment of your overall pipeline? Recursion in the pipeline calling stack can lead to locks. * Why it is blocking (I guessed it is blocking due to resource exhaustion) My guess is that the requests are simply coming in faster than XMLFileModule is taking to release the lock. That's not important, IMHO. Problem is in pool's lock, not XMLFileModule's lock. Are you sure?
Re: Cocoon hang in excalibur-pool
Ralph Goers wrote: OK. I'm wondering if the real problem is simply that the getDocument method is completely synchronized? As far as pools go, I feel like a complete idiot. See my comments below. Vadim Gritsenko wrote: Ralph Goers wrote: Thanks Vadim. I'm posting this back to the Cocoon list as it seems what you are telling me is that the problem is either with the XMLFileModule or with running out of components in the pool on the pipeline being invoked. What I am not clear on is what you are trying to tell me in the last paragraph. Are you saying that the deadlock can be avoided by configuring the components being used in the target pipeline differently? I've not looked into pool source code yesterday to double check all points myself. I'm suggesting you to check: * What type of pool is really used Where is that specified? I know you can specify what type of pipeline you want but where is the type of pool configured? It is not a blocking pool, although the DataSourceComponent uses a blocking pool. If you run out of connections, it will block. Everything else acts like a factory when over the limit. * Why it is blocking (I guessed it is blocking due to resource exhaustion) My guess is that the requests are simply coming in faster than XMLFileModule is taking to release the lock. That is a possibility--if the method being called is static or belongs to a ThreadSafe component. * If it's hard limiting pool - why it's not soft limiting pool Again - is that configured somewhere? Unless you specifically set up a pool in your own component, it is soft limited.
Re: Cocoon hang in excalibur-pool
Vadim Gritsenko wrote: Ralph Goers wrote: Also, Do you know why Document helper is declared static? DocumentHelper *class* is static. Why it should not be? Is DocumentHelper an inner class? If so I agree, all that the static on a class means is that the inner class can (should?) be in a separate class.
We need this chart
http://headrush.typepad.com/photos/uncategorized/kickasscurve_1.jpg I say we take the chart, superimpose the Cocoon versions over it and make it happen. Don't we want to reduce the time it takes users to "kickass"? The article it came from is located here: http://headrush.typepad.com/creating_passionate_users/2005/12/but_is_it_inter.html
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Vadim Gritsenko wrote: Niclas Hedhman wrote: On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote: For the versioning, we could for example release a 2.2 soon, change the environment abstract after that and then release a 2.3 later this year. Two more releases this year, YEAH!!! That's a remarkable spirit ;o) Just kidding... I think Carsten is right, stablize and release 2.2 ASAP. There is no +1 large enough to convey how much I agree. Considering we had/have issues with switching the build system, adding the Environment removal will only push the release out further. I'd propose solidify 2.2 as is and push it out. You want to get rid of Environment, make that a focus of 2.3.
[RT] Changing Abstraction
IMO, abstraction is not bad, however the wrong abstraction is. Using
the right abstraction can make using a library or tool much easier to
grasp and use.
Now, I'm sure you are sick of Ruby and Rails, but I'd like to share a
little about how the user interacts with the environment there. It
might help us come up with a decent abstraction here. First, there is a
huge difference between the ease of using Maps in Java and Ruby, so they
are more prevalent in Ruby apps. Here is what it looks like to get your
parameters in Ruby:
val = @request['name']
What is "cool" about the integration in Rails is that you can have a map
of maps to populate an object for you like this:
obj = MyObject.new(@request['object'])
Any elements input from the form for 'object' automatically get
associated with the data elements in the MyObject instance. This is a
wonderful time saver, and it provides easily groked code. Of course,
this association is based on a naming convention that takes care of the
abstraction. If we ever wanted to replace a value in the request
object, we would do something like this:
@request['name'] = val
Which means that your request parameters are not read only. Again more
flexibility.
To me, this works. It is emensely simple, and it is yet another
abstraction above the native CGI abstraction for Ruby code.
I'd like to see something similar for Cocoon. Not for the 2.2 release,
but for a future release. I know we can't have the same syntax in Java
that we do in Ruby, but why not allow something like this:
val = request.get("name");
obj = request.decorate( "object", new MyObject() );
// template public T decorate( String name, T object );
request.put("name", value);
Just a little note about the Factory function. If the class was a
normal JavaBean, we could use the bean utils to set the parameters from
the map returned from the request object. That would keep the user from
having to write the same code in every object they created. It is about
as close as we can come to adding methods to objects at runtime like you
can in Ruby. Defining a nice little convention like that can make
developing in Cocoon fairly nice.
The session handling in Ruby is very much the same, so there is no point
in going into detail there. What is noticeable is the lack of a direct
interaction with a response object. I like that aspect. That's what
the pipelines in Cocoon are for. I'd also like to see what we can do to
hide any possible need for the Context object from the Servlet spec.
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Gianugo Rabellino wrote: On 12/13/05, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: I agree that the main focus must be to get a 2.2 release. So the question is what to do with the real blocks. They are currently rather close to the "specification", but we don't know if the specification is good enough without getting experience from the blocks. For ditching the environment abstraction, that should of course not block any releases. It can always be solved by making the change in a branch and merge it back when it works. I tend to disagree. The environment abstraction is to me part of the underlying public contracts users rely upon: changing contracts between minor versions is borderline but acceptable given the cost/benefit ratio, but it's out of question between revision. Having 2.2 with the old environment and, say, 2.2.1 with a new one seems like breaking our versioning guidelines to me. I'd suggest we ditch it altogether while we still have time. Ciao, Just make sure it doesn't break anyone accidentally.
Re: [RT] Ditching the environment abstraction
Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten I would imagine for a leter version. I'd think it would be too soon. We have two implementations of the Cocoon environment abstraction: CLI and WebApp. If we rip out the abstraction now, Forrest would break. I think that alone would push it out a bit.
Re: Cocoon F2F at ApacheCon
Upayavira wrote: Matthew Langham wrote: I really think the current discussions on CocoonReloaded could do with some higher bandwidth talks to formulate a first "plan". How many Cocoonites will be at ApacheCon and could perhaps get together? I won't be there but Carsten is (for example). I don't think you'll be able to stop us! Discussing the "plan" via various email-threads doesn't seem to me to be that effective - at this initial stage - and could eventually lead to everyone giving up in frustration. But at the same time we don't want to leave out thase that are not there. Right. I won't be able to make it this time, but I'm making plans for the one in the Spring. (We'll see how that goes, we're spending alot of money on our 10th aniversary so I may have to delay until next winter)
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Wednesday December 07, 2005 6:26 pm, Thomas Lutz wrote: > Though I am not a dev guy, I can't resist to vote, too. IMHO a mix makes > no sense. Too make a long story short I made struggled my way into > cocoon with > Last comment: Though this is not the question in this poll, I would even > kick out the pipeline xml stuff. XML was not designed to be > "procedural", basically it's a markup language, which focuses on data > exchange. In my vision we can keep our pipelines, but remove most (if not all) of the XML configuration crap. Just some good solid conventions like rails. > > On a recent open source talk in vienna a committer from RoR was joking > about the java frameworks and their tons of configuration and even worse > "flow" description files. Though the RoR approach goes a bit too far for > a compiled language like java, I do believe it makes sense to stick to > the language choosen. Oh yes, spring flow... > > So, please :-), only one language, and as cocoon (or whatever it's name > will be :-) ) is a J2EE framework: _Java_ I hear you, and hopefully even more. > > Sorry for the interference :-), regards, > tom > Please interfere. Users lurking on dev are more than welcome to contribute their oppinions.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Aurélien DEHAY wrote: Hello. Sorry for the intervention of a non-dev on the dev list, but shouldn't this question be asked on the user mailing list? :) Yes and no. Check this article out for more information: http://headrush.typepad.com/creating_passionate_users/2005/09/listening_to_us.html In all honesty, while we are day dreaming about our vision we don't necessarily want to alarm users or generate too much noise on the user list. However, since you are on this list, your input is valued if you have any.
Re: An entirely new beast
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) No, CS3 implemented on the cell processor ;P
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
So far it seems as if we are looking at two options: Pure Java or status quo. And so far we are something along the lines of 2 for Java and 2 (possibly 3) for status quo. Anyone else have input? Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto: What's your preference for the vision? [ ] All web apps written in JavaScript [X ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today) Ugo
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Ross Gardler wrote: Berin Loritsch wrote: I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts). Sometimes, DSL's bring many benefits, just consider the sitemap. Do we want to know more or is this a step too far at this stage of discussion? I'm aware that t could go off on a horrible tangent and we'll never find the real vision, it may be better for me to bring this up again at a more appropriate time, after all its an implementation detail. I think that is enough for this part of the discussion. I'm just trying to help us get aligned at the basic, core level. Nothing would prevent what you want to do in Cocoon.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Ralph Goers wrote: None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. Shudder. That could be a nice add on to Cocoon. Perhaps a BPL (Business Process Language, an XML standard for what you are talking about) application. I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts).
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
hepabolu wrote: Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) With Ajax and other bells and whistles on the client side, there will always be javascript. I'm focused on the server side. I'm not even contesting the client side use of javascript.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [X] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
[Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
In the exchange below I did some creative snipping to emphasize where we are not 100% aligned on vision. Below I will bring out my points, knowing that I'm not the guy who sets the tone for Cocoon. Torsten Curdt wrote: Berin: ... I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. ... I envision a Cocoon where I only have to learn Java and XML to be affective. ... Sylvain: ... I envision a Cocoon where people can use a single unified scripting language for both the client and the server. ... Torsten: ... I envision a cocoon where flow is not a 2nd class citizen. The conflict in vision is actually between Sylvain and I. OK, conflict is a strong word, more like we are not on the same page. Both Sylvain and I are aligned with Torsten, but we most likely have different ideas on how to get there. Bottom line: I am in favor of Java Flow, and avoiding embedding any scripting languages in the core. If you want to add a scripting language front end, I would suggest it be an add-on. Why? Because it both simplifies the design, and it minimizes the number of things the user (in my experience it is always a Java developer) has to learn before they can be effective. I can infer from Sylvain's vision that he sees value in using JavaScript on the server as well as on the cient. And why not? We have the solution already in place. Now, the Pros of using JavaScript that I can see are as follows: * Common syntax on server and client * Easy to use Java objects in JavaScript code * Easy to add support for continuations The cons I see are as follows: * API depends on bound objects (not consistent between client and server) * No testing framework for JavaScript Code * Requires embedding a JavaScript runtime in the server * We can't use the same debugger in our IDE to step through server side JavaScript code * No IDE support for JavaScript * It's another language to have to learn The testing framework for JavaScript is easily overcome. We could create something to get that working. In Java 6 (still being worked out) JavaScript is supposed to be embedded into the core, so when the IDEs tool for Java 6, my objections involving IDE and debugger will go away--but that is a ways off still. Which leaves us with the API con and the learning con. I will stick to my guns for my belief that JavaScript will fail in its mission to bring "less technical" people to work on the server side. Less technical people need all the handholding they can get, so without IDE support and a well defined API they won't know what to do. That does not mean that JavaScript is evil, or that it doesn't have a place on the server or in Cocoon. I just think we are kidding ourselves if we think it will allow less technical people to do a programmer's job. Now, my chief goal and my chief vision for Cocoon is to simplify the number of concepts a user has to learn before they are effective with Cocoon. That might mean that we provide JavaScript as the only way to interact with the core. All web applications would be written in JavaScript from control to helper functions. Or all web applications would be written in Java from control to helper functions. It is incredibly awkward to mix and match as the default way to do things. It is difficult to explain when and where to use which language. Now, for advanced users who don't mind the mix and match, I have no problem with having tutorials on how to do that properly. What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
Re: An entirely new beast
Upayavira wrote: I've been thinking more about Sylvain's proposal and ideas. And would like to suggest a way to look at it and see how it fits into the context of what we already have. Sylvain is proposing something different, something that is likely to be almost entirely incompatible with the existing Cocoon. If it is almost entirely incompatible, how can we think of it as in some way being a _continuation_ of what we already have? This, it is _not_ Cocoon 3.0. It is something else. Thus, I agree with Sylvain that it should have a new name, but think that Raccoon is a bad one, as it is a play on Cocoon and could never really be the project's real name. Imagine it, "powered by Apache Cocoon Raccoon". Hmm. Well, let's at least get on the same page with what the vision should be. I'd rather have that discussion first.
[Vision] Knowing When We are Done
In all the talks of redesign or not, there has been a recurring question as to the vision. Sylvain has outlined some things that he would like to see, but they really don't constitute a vision. They are a nice list of improvements, but they aren't a vision. In my experience the best visions really don't have to do with features and improvements, but with what we expect to be able to do with Cocoon. We need to be able to put our vision statement in one or two paragraphs, and it needs to convey a little more than technology. Visions contain emotional content as well. There are two kinds of visions. One is the kind that you use to attract users, "Oh, that's what I need and they approach things the way I expect". That's the kind that ends up on the front page. Then there's the kind of vision that explains how you think something should be done. Kind of like a how-to that describes what _should_ be instead of what is the case. It has to be something exciting, something that people can get behind. Now, whether we are talking about evolutionary change or revolutionary change, we need to have a common vision. How else will we ensure the transition goes as smoothly as possible? Good foundational principles of modern software development are just side issues. Let's take a look at what we want Cocoon to be. Below is my vision, which I hope starts discussion. We can start consolditing the common points once people post their visions. Let's gather the information, and then see if we can look at some commonalities and think a little outside the box to make as many of us happy as is practical. Berin's Vision I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: "I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications". I'm thinking solutions like user authentication, portal support, or other generic solutions. - That's my vision. What's yours? How much overlap is there? Let's start this discussion, I think we will be pleasantly surprised how close many of us are with where we want Cocoon to go.
Re: [RT] The next shiny thing?
Daniel Fagerstrom wrote: Berin Loritsch wrote: I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. You know Berin, we have blocks. Go and read http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113335919919804&w=2. It says something interesting about this community that no one have responded to that message yet. While a thread about marketing and branding absorbs all the community energy (again). :) Yes I know we have a certain implimentation of blocks that require compiling against the core. Is Cocoon all about talk and hype? Is design and programming, and god forbid refactoring and testing, something old fashioned that we better stop worrying about? Oh I agree that design, programming, refactoring, and testing are all extremely important. Any attempt to do a redesign *must* have these things working if it is to have any hope to succeed. I just believe that we have gotten to a point where retrofitting these things is going to take more time and energy than it will to establish them at the inception of any new efforts. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. Wow! isn't marketing talk fun. Yes it is. But don't forget to see the substance behind it. The reality is that the world around us has changed, and ignoring that fact is just as unhealthy as doing a complete redesign every release. Still I fail to see a common coherent vision for this revolution besides that current Cocoon is messy. Sure I have seen that Sylvain have collected some ideas that we have discussed on the list for a while. Much of it that great stuff, but is it something that can't be achieved by refactoring Cocoon? And are they so great so that we should spread ourselves even thinner instead of focus on getting 2.2 out of the door? Right, and we do need to solidify the vision. I think the point where we are is still trying to see if there is enough community support to do a redesign. Nevertheless, we do need a common vision for Cocoon, whether that is 2.2, 2.3, 3.0, or X. That way we can be sure that we are evolving the right direction. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. I don't think anyone has suggested that we abandon 2.2. Yes, we need to finish 2.2. We need to manage the TODO list for 2.2. I know about the pain of restructuring Cocoon as I'm have worked with core related stuff for along time. And getting some proof of concept code working might not be that hard. But I think that you severly underestimate the amount of work it will take to get a production quality system shipping. Not to talk about getting the trust in the new product when we anounce: "trust us, this time is different, this time we will behave responsible" That's why I have always advocated the release early and often mantra. I think we should institute a monthly early access release, so that we can get the feedback we need at each stage. I would advocate that whether the community goes evolutionary, revolutionary, or some hybrid.
Re: [RT] The next shiny thing?
Daniel Fagerstrom wrote: To me: * throwing away the collected work of the community * building something rather different * throwing away a strong brand * leave all the users who has put a trust in us behind seem like a rather strange way of "saving" Cocoon. It seemed like a rather strange way of saving Apple as well, but look what happened. Now I agree about the point on "throwing away a strong brand", because the focus of any revolution here is to clarify and crystalize how to use Cocoon efficiently. Now, the point of "leave all the users who has put a trust in us behind" is a bit of hyperbole IMO. This community successfully made that transition once before. I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. For you attention seekers out there, OSGi based blocks will draw a lot of attention towards Cocoon, and it is innovation, not immitation. /Daniel :) Honestly, too little, too late. Just how much attention has OSGi received over the years? It's been around at least as long as Avalon, but Avalon received much more attention (albeit negative attention). It has been living quietly behind the scenes now for a long time.
Listening to Users? Or Doing what we think is best?
Here is a wonderful article at "Creating Passionate Users": http://headrush.typepad.com/creating_passionate_users/2005/09/listening_to_us.html There are many things we can learn from this site--its fun, and it challenges the status quo. If we are going to rock the boat a bit, we need to take stock and think a little differently about things.
Re: 2.2 vs 3.0, or 2.2 then 3.0?
hepabolu wrote: More important I think is not only defining the "vision of Cocoon 3.0" as precisely as possible (so all jumping up and down now, know exactly where to jump in), and coming up with a roadmap, but also to try and define/write conversion tools (however simple) almost from the beginning that can ease the transition from 2.1/2.2 to 3.0. If the tedious 60% can be done automatically, it shows the current user base they are not abandoned. AND PLEASE TAKE THE DOCUMENTATION INTO ACCOUNT! However rudimentary, write something, give an example and make sure the docs stay up-to-date. I agree. I've done my part with 2.0/2.2 documentation. I've done my part with Avalon documentation. I'd like to point out that there are a couple levels of documentation: 1) Unit Tests 2) Formal Docs Now, I think it is reasonable to have the average developer to do Unit Test documentation. IOW, the unit tests are your first example of how something is used. Formal docs require some skills that many developers don't have--esp. if English is their second language. It's one thing to understand how something works, it is quite another to describe it to someone else. It becomes even harder when you throw an unfamiliar language into the mix. It would be very helpful if we could all work together, those of us who are good at documentation and those of us who are good at developing solutions.
Recent Short Story Why We Need Something New
I'm not going to take too long, but this is just anecdotal evidence of why I think Cocoon 2 is stagnating and we really need a Cocoon 3. Let's roll back the calendar just a couple short months ago just before the Cocoon Get Together. I proposed a change to the way Cocoon would process a request. Now, in the original 2.0 code it would have been fairly easy as we had a pretty simple Processor interface. I received lot's of "why write Java code when you can use JavaScript" comments. The "you can do that already, just set your Sitemap like this, and set up a flowscript like that, and viola" approach was really more complex than I wanted. I dared to ask the question, "why?" It would become just meaningless cruft to do that. So I made the statement "let me show you what I mean" and I started something in the whiteboard called "crails". It became immediately apparent that I could not possibly do what I wanted with the current architecture. Too many concerns made their way into the Processor interface, and I would _need_ to rewrite _major_ portions of Cocoon code just to provide an alternate processor to the Sitemap. Honestly, at this point, it would be easier to just start Cocoon over from scratch trying to fit in as much as I could from the existing codebase. But it was ugly and I really wasn't comfortable doing that without more than _just_me_ doing the work. I'm a busy guy, and I can contribute here and there. I can whip up a few simple solutions but I can't rewrite Cocoon on my own. I'm reading two books, writing one, doing OSS, and that's all in addition to my day job and family. To be honest, we need to cater to people just like me. It shouldn't take a long time to get into the internals of Cocoon. Even if I never do get into the internals, I should be able to do some value add. I shouldn't need to learn seven different tools and languages just to do something simple. There should also be the principle of ever deepening knowlege. Looking at things from the electronics perspective, building a solid state electronics based mic amplifier is very simple because op-amps are built to tolerance, and they don't require alot of finessing. As a result you can build much more into the amplifier, such as filters attenuators, etc. Contrast that with tube electronics, and its a different story. Yes, the final circuit board for a tube system is simpler, but there is so much math and fine tuning just to get the thing to work you are just happy you've got something that amplifies your microphone. You don't care about attenuators and filters, because they would be too much effort. The tolerance on tubes are not nearly as strict, so your circuit may work with the next tube or it may not. It depends on a few factors. Cocoon 2 is like working with tubes. There is so much up front work that as a user I am just happy I have something that works. Adding all the fun stuff for my users tends to go on the back burner because I wrestle with the framework. The solution? Well either change Cocoon, or change frameworks. For me, I decided to change frameworks for my personal projects. My needs don't require all the power of Cocoon, but it would be nice to provide some options.
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Upayavira wrote: So, 2.2 = important, and 3.0 = important. Both. We need to avoid discussions, implications, emotions, etc that suggest otherwise. Right. If any of that has gone on, I'm sure its unintentional. If memory serves me correctly, Cocoon 2 was written as a branch, and Maintenance was happening on Cocoon 1 for a while. There did come a time when work stopped on Cocoon 1, but that was after Cocoon 2 was released. Basically, new/exciting stuff should go in Cocoon 3, and touch ups to Cocoon 2 until Cocoon 3 is ready for prime time.
Re: [RT][long] Cocoon 3.0: the necessary mutation
On Sunday December 04, 2005 2:49 pm, Joerg Heinicke wrote: > On 03.12.2005 05:58, Berin Loritsch wrote: > > Why is Ruby on Rails fun to work with? It is because > > things make sense. You only need to learn Ruby to be able to create a > > useful website. You don't need to learn Sitemap Markup Language, JEXL, > > CForms configuration language, Hibernate mapping language, Javascript, > > XML Stylesheet Language, and core configuration language. > > But don't we agree that RoR works just up to a certain complexity? And > that targeted Cocoon applications are beyond this complexity? So > comparing concepts or what to learn to effectively use a technology is a > bit unfair, isn't it? > No, I think that's a cop out. RoR has something that Cocoon *needs*: simplicity. Web sites don't need to be overly complex. In fact, most "complex" web sites only need a _little_ bit more than what RoR affords you. My point is this: Cocoon does not need to be nearly as complex as it is. If you never stop to see what you can learn from another web framework, you will always assume that "my needs are just too complex". It just ain't so. Tell me, why is it so much easier to integrate a web service or two right into your RoR app compared to a Cocoon app? Ok, maybe that was unfair. How about automatically generated emails? Oh, again probably a little unfair. What Cocoon has that is still difficult in RoR is the ability to generate PDFs. Much of the complexity in Cocoon today is _self_inflicted_. Cocoon is just not fun to work with. What's wrong with adding a little fun back into using Cocoon? Can you give me an example of a web application that you think would be too complex for rails but just right for Cocoon? Now, let's go the other way. Create a blog in Cocoon, and compare it with one written in rails. How much cruft and unnecessary work in each one? Bang for buck rails kills Cocoon. It doesn't need to be that way. Bottom line: so what if Cocoon is marketed for stuff more complex than rails? That's still not an excuse for the complexity we put ourselves through. I want my work to be fun--or at the very least efficient. You can't be efficient if you have to learn several languages just to get going. Esp. since you can't expect to be an expert in any one of them.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: Berin Loritsch wrote: There are two antipatterns that I see with Cocoon as a whole (from the current design aspect): Alphabet soup syndrome, and mixed metaphors. The alphabet soup syndrome has to do with the fact that we are buzzword compliant without really taking the time to consider the affects on the whole. The mixed metaphors has to do with all the components that overlap each other such as XMLizable and Generator. Every component should have a reason for being, and it should compliment the other components that already exist. If you want to propose a new component that happens to overlap the responsibility of an existing component it is probably time to see which of the two is really needed. Perhaps the older one needs to be retired. When you look at the sitemap, it is not configuration--even though there is some configuration information in there. A sitemap is a domain specific language expressed in XML. My personal oppinion is that XML is poorly suited for any programming language. The sitemap is a powerful concept--it is the implementation that feels a bit unnatural. Think with the hat of someone who has never looked at Cocoon before. You can probably assume that they have programmed in Java--but that's about it. You can't assume that: Cocoon is also one of the very few frameworks that allows people with little programming knowledge to do some non-trivial stuff, and we should not loose this goal. That's why I consider keeping JavaScript as a glue language something important. I don't know about you, but the reason most folks I know consider Cocoon is because it is written in Java. I can guarantee you that not one non-technical person has ever tried to contribute anything more than a use-case spec to a Cocoon project I have worked on. Why? Because its not their job. I would argue that JavaScript is not necessarily easier than Java. It's different, but not necessarily easier. Your person with little programming knowlege is going to be just as uneasy with JavaScript than Java. The problem with JavaScript has to do with the fact that there is no IDE support. There is no autocompletion. There is no debugging. There is no sane way to do test driven development with JavaScript. Sure you get the scripting easy turn around, but you would also get that with JRuby. And JRuby has a unit testing framework so it would have a leg up. The problem with an inconsistent environment is that in order for us to make it consistent, we would have to create a series of JSR 198 compliant IDE plugins for the integrated languages. Oh, and wait for IDEs to ship with JSR 198 support. I don't think anyone wanting to work on Cocoon is in the IDE business. When you have one consistent language, you leverage the work of others for your tool set. Nothing special is required. I honestly believe that direct interaction with JavaScript is not the way to invite people with little programming experience. But that's my two cents.
[RRT] Cocoon 3? Defined by what it doesn't have
If Cocoon goes for a 3.0 approach, I would have to argue for a more radical approach than "just fix things here and there". The problem is one of focus. On paper Cocoon is a very capable framework. It introduced us to a great new world of dynamic web sites. It's caching system kicks tousche. And yet, the old guard is moving on and the new guard doesn't know where to start. How do you go about creating a simple web application? How do you integrate a couple web services into a larger app? How do you do forms? etc. Cocoon 2.0 is like Visual Studio.NET. On paper there are a hundred things that kick but. When you use those features, it does make your life easier. However, we don't allways use the cool features every day. There are some things that would make every day life even better such as programming by intention and refactoring tools. It just feels like the same old thing rehashed and a couple features added on. It should be like JetBrains IDEA. Almost every feature that is included somehow makes daily development life easier. There is an early access program to draw feedback from the user base. You don't have to think about the features that you need because they are right there. Even better is that the features are where you need them, and they aren't obtrusive. You don't necessarily notice IDEA by itself, you notice it by its absence. We need to ask ourselves some hard questions: Do we really need it? (It being whatever feature up for discussion) Does it make the user's life easier? Can an Average Joe understand it? How does this fit in with the overall vision? What is the overall vision? I may be off base here, but I believe the majority of Cocoon's users are developing /interactive web sites/ and not statically published sites. The original vision has changed, but the enertia behind the implementation has made Cocoon slow to adapt. What we need is _just_enough_ to get the job done. There should be _one_way_ to do things. Options don't make life easier--they make negotiations easier. Are there things in the cooker that will put Cocoon in the sweet spot? Absolutely, but fitting them into the current architecture has been difficult. I'd assert because there are too many ways of doing the same thing. What about Risk? There is risk involved in any start over/redesign. Now, I have been involved in three wholesale redesigns of software at the various companies I worked for in the past. Each one of them has been successful because of the approach I take in doing it. I use every experience to help make development and design better. Here is the basic outline of the process: 1) Decide on a regular release schedule and employ a FedEx method of development. For example, Cocoon 3 should be released AS IS every month. The first versions may not have a whole lot there, but it should give an indication of where we are going. This is our Early Access Program. 2) Test First Development. By writing tests _first_ we have a feeling of _how_ something is used. It is our first feedback of whether or not we are barking up the right tree. If we don't like the results ourselves, it is doubtful anyone else will like it. 3) Forget the "Everything is a Component" mentality for a bit. Let's see just how far containerless programming takes us. You might be surprised. The number of moving parts is/should be relatively small. Lets just start with good OOP to begin with. 4) Focus on the essentials. Deliver the most important things first. Focus on stability and understandability at each stage. Compare how the new feature is implemented with the whole. There should be a continuity. You should be able to say that things "just work" and everything "just fits". You will be surprised at how quickly you can get to a point where Cocoon 3 is ready for prime-time. The fact that it will be much easier to use than its predecessor will generate the excitement. We will have to measure success by "gee its easy to do this in Cocoon, why is it so hard here?" Forget about the wizbang hollabalou of featuritis or even providing a solution for the XML technology du jour. Start with good foundational principles. SEE HOW MUCH WE CAN LEVERAGE EXISTING TOOLS!!! We need to see things from the eye of a user. If Cocoon is going to make it through the long haul, it needs to pick up momentum. It will only do that if we can generate excitement. Excitement surrounding some new whizbang feature is temporary. Excitement because Cocoon saves time and doen't require significant ramp up to understand it lasts much longer. If you can tell a manager that they will save money by using Cocoon, and prove it, then it will have a higher adoption rate in corporate america. To obtain that goal it has to be solid. It has to save time that would normally be spent writing config files or mapping files. Etc. Don't worry about things like database integration at this time. There are other tools t
[RRT] Cocoon 3? Defined by what it doesn't have
If Cocoon goes for a 3.0 approach, I would have to argue for a more radical approach than "just fix things here and there". The problem is one of focus. On paper Cocoon is a very capable framework. It introduced us to a great new world of dynamic web sites. It's caching system kicks tousche. And yet, the old guard is moving on and the new guard doesn't know where to start. How do you go about creating a simple web application? How do you integrate a couple web services into a larger app? How do you do forms? etc. Cocoon 2.0 is like Visual Studio.NET. On paper there are a hundred things that kick but. When you use those features, it does make your life easier. However, we don't allways use the cool features every day. There are some things that would make every day life even better such as programming by intention and refactoring tools. It just feels like the same old thing rehashed and a couple features added on. It should be like JetBrains IDEA. Almost every feature that is included somehow makes daily development life easier. There is an early access program to draw feedback from the user base. You don't have to think about the features that you need because they are right there. Even better is that the features are where you need them, and they aren't obtrusive. You don't necessarily notice IDEA by itself, you notice it by its absence. We need to ask ourselves some hard questions: Do we really need it? (It being whatever feature up for discussion) Does it make the user's life easier? Can an Average Joe understand it? How does this fit in with the overall vision? What is the overall vision? I may be off base here, but I believe the majority of Cocoon's users are developing /interactive web sites/ and not statically published sites. The original vision has changed, but the enertia behind the implementation has made Cocoon slow to adapt. What we need is _just_enough_ to get the job done. There should be _one_way_ to do things. Options don't make life easier--they make negotiations easier. Are there things in the cooker that will put Cocoon in the sweet spot? Absolutely, but fitting them into the current architecture has been difficult. I'd assert because there are too many ways of doing the same thing. What about Risk? There is risk involved in any start over/redesign. Now, I have been involved in three wholesale redesigns of software at the various companies I worked for in the past. Each one of them has been successful because of the approach I take in doing it. I use every experience to help make development and design better. Here is the basic outline of the process: 1) Decide on a regular release schedule and employ a FedEx method of development. For example, Cocoon 3 should be released AS IS every month. The first versions may not have a whole lot there, but it should give an indication of where we are going. This is our Early Access Program. 2) Test First Development. By writing tests _first_ we have a feeling of _how_ something is used. It is our first feedback of whether or not we are barking up the right tree. If we don't like the results ourselves, it is doubtful anyone else will like it. 3) Forget the "Everything is a Component" mentality for a bit. Let's see just how far containerless programming takes us. You might be surprised. The number of moving parts is/should be relatively small. Lets just start with good OOP to begin with. 4) Focus on the essentials. Deliver the most important things first. Focus on stability and understandability at each stage. Compare how the new feature is implemented with the whole. There should be a continuity. You should be able to say that things "just work" and everything "just fits". You will be surprised at how quickly you can get to a point where Cocoon 3 is ready for prime-time. The fact that it will be much easier to use than its predecessor will generate the excitement. We will have to measure success by "gee its easy to do this in Cocoon, why is it so hard here?" Forget about the wizbang hollabalou of featuritis or even providing a solution for the XML technology du jour. Start with good foundational principles. SEE HOW MUCH WE CAN LEVERAGE EXISTING TOOLS!!! We need to see things from the eye of a user. If Cocoon is going to make it through the long haul, it needs to pick up momentum. It will only do that if we can generate excitement. Excitement surrounding some new whizbang feature is temporary. Excitement because Cocoon saves time and doen't require significant ramp up to understand it lasts much longer. If you can tell a manager that they will save money by using Cocoon, and prove it, then it will have a higher adoption rate in corporate america. To obtain that goal it has to be solid. It has to save time that would normally be spent writing config files or mapping files. Etc. Don't worr
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: Hi all, For many years, I have been more than happy with Cocoon, enjoying the power and ease it brought for both publication and webapp projects. Over the last months however, other feelings have emerged: there are things that are definitely overly complex in Cocoon, and there have been some emerging frameworks leading to "wow, cool!" reactions rather than "yeah, yet another one". Also, I strongly believe that the Ajax revolution is quickly obsoleting the traditional reload-page-on-user-action model that prevailed on the web up to recently and requires frameworks that help building these new kinds of applications. All this to say that if we want Cocoon to have a bright future, it must go through a mutation. This RT dumps my current ideas about this, depicting something that IMO better fits today's needs while taking into account many years of innovation and what we learned from them. If I may, I'd like to suggest a process for identifying what should be, and how to make the design decisions. Bear with me a bit as I use something totally unrelated to programming in general. When a traditional Japanese sword polisher goes about a new project, he arranges his tools in his workspace so that he does not have to think about which one he needs next. His tools are essentially a set of progressively finer grained stones and water. The polisher starts with the course grained stones to set the geometry/structure of the blade in place. As he works in one small area, he constantly checks his work against the whole blade. Uneven, or inconsistent work will ruin his efforts. As he progresses toward the fine grained stones, he is concentrating on bringing out the subtle detail forged into the blade itself. Again, all the time checking his local work against the whole. Now, I said all that to say this: Simplicity is fun to use, but hard to do. You have to take a process like the sword polisher in order to arrive at something brilliantly simple. Little things matter. If you can make the user's life even just a little bit easier, it is a worthwhile goal. As you add a new feature, use it a bit and ask yourself if it is making your life easier or harder. There are two antipatterns that I see with Cocoon as a whole (from the current design aspect): Alphabet soup syndrome, and mixed metaphors. The alphabet soup syndrome has to do with the fact that we are buzzword compliant without really taking the time to consider the affects on the whole. The mixed metaphors has to do with all the components that overlap each other such as XMLizable and Generator. Every component should have a reason for being, and it should compliment the other components that already exist. If you want to propose a new component that happens to overlap the responsibility of an existing component it is probably time to see which of the two is really needed. Perhaps the older one needs to be retired. When you look at the sitemap, it is not configuration--even though there is some configuration information in there. A sitemap is a domain specific language expressed in XML. My personal oppinion is that XML is poorly suited for any programming language. The sitemap is a powerful concept--it is the implementation that feels a bit unnatural. Think with the hat of someone who has never looked at Cocoon before. You can probably assume that they have programmed in Java--but that's about it. Now think about the number of technologies that someone has to learn in order to be affective with Cocoon. If we have Javascript, Java, Jexl, etc. we are introducing complexity and learning curve because we haven't thought how to use Java better. Think of tools like Hibernate and CForms. Both store metadata in XML that can be captured in a Java object or in database metadata. If we use Java 5 as the standard minimum JVM for Cocoon 3, we now have access to a couple nice features to enhance CForms. Annotations are a powerful feature, and we should be looking for ways of using stock Java in new and better ways. Why is Ruby on Rails fun to work with? It is because things make sense. You only need to learn Ruby to be able to create a useful website. You don't need to learn Sitemap Markup Language, JEXL, CForms configuration language, Hibernate mapping language, Javascript, XML Stylesheet Language, and core configuration language. There is a difference between configuration and convention. Convention is the process of describing things by similarity. Configuration is the process of describing things by difference. Since we can only juggle so much at a time in our minds, guess which one wins? I would venture to say that 90% of what goes in the Cocoon configuration file is untouched. Why does there have to be a configuration item for it then? I think what would be fun, and easier to learn for newbies, is to see just how much we can get Java to work
Re: "Standalone" components?
Max Pfingsthorn wrote: Hi! I've had a bit of trouble with components that are not referenced by others. I need to start (i.e. service, configure, initialize, etc) a component once the container is started. Can I do this somehow? I noticed an attribute called "activation" (next to "logger") which can be set to "inline" in cocoon.xconf, but that doesn't seem to work. Xdoclet tags for avalon like "@x-avalon.lifestyle type=singleton" and things don't do it either (yes, I do extract the metadata in my build process). FYI, Cocoon is not using Fortress, so the XDoclet tags aren't going to do anything for components in Cocoon.
Re: How much longer for the issue spamming?
On Tuesday 25 October 2005 10:18 am, hepabolu wrote: > Berin Loritsch wrote: > > In the period of about 12 hours there has been over 120 messages > > generated by JIRA. All to do with opening and closing issues, etc. > > > > While it is to be expected that the introduction of the new tool is going > > to require some rampup time, Its hard to see the real mail traffic. > > > > Is there any way to have the messages sent to this list in digest form? > > That would cut down on the traffic allot. > > I'm done now. So traffic should be lower now. > > Bye, Helma Thanks. Is it still possible to have digest emails sent to the dev list instead of one per alteration? I think that is the most sensible option to minimize the signal to noise ratio on the list.
How much longer for the issue spamming?
In the period of about 12 hours there has been over 120 messages generated by JIRA. All to do with opening and closing issues, etc. While it is to be expected that the introduction of the new tool is going to require some rampup time, Its hard to see the real mail traffic. Is there any way to have the messages sent to this list in digest form? That would cut down on the traffic allot.
Re: [IMP] Code freeze starts tonight
Ralph Goers wrote: The code freeze for the 2.1.8 release starts tonight and ends next friday (hopefully) with the release of 2.1.8. The usual committing rules for a code freeze apply. We're on subversion right? What's wrong with creating a branch for 2.1.8 release candidate and finishing that off without freezing all of development work? Even better, all transactions are atomic (so we won't have half commits or half branches) and the merging works alot better.
Re: ApplesProcessor - a little crazy idea
Mark Lundquist wrote: On Oct 13, 2005, at 8:42 AM, Sylvain Wallez wrote: I never used Apples, but it looks like some people (and not only their original creators) are using it. I never really did "get" Apples. Can somebody just sort of give a quick summary of what it's all about, and why I would want to use it? If it's to become one of the "official" flow implementation, what about changing its name? "Apple" has really no relation to page flow, whatever meaning of the word we consider. yeah... for real. :-) Oh man! I was going to come up with a competing standard called "Orange" just so we could have Apples to Oranges comparisons! ;P
Re: Removing author tags (again)
Torsten Curdt wrote: What has stopped us is that we need to keep a track of these to give credit. And also show to the world the incredibly large developer group we are :-) But if you give credit without a connection to parts of the code it's just a list of the committers (more or less) If you *have* a connection people will look people up in there... So either remove them or don't. But giving credit besides the community credits does not make much sense to me. *shrug* You know, I still get people emailing me about some code that I wrote well over two years ago just because my name is in the author tags.
Re: Removing author tags (again)
Sylvain Wallez wrote: Carsten Ziegeler wrote: I think a long time ago we decided to remove the author tags, upto now nothing really happend :( Yep. There was a positive vote (probably more than one actually), and since then nobody adds new @author tags, meaning the information is really not accurate. What has stopped us is that we need to keep a track of these to give credit. And also show to the world the incredibly large developer group we are :-) Traditionally (on C based applications) this is done with a CONTRIBUTORS file in the root of the project.
Further clarification about the CRACK type resource resolution
I did some further reading from my "Agile Web Development with Rails"
book, and found out that while the normal idiom supported by Rails is as
I originally specified, it is relatively easy to modify.
All the routing is specified in the conf/Routes.rb class. The Routes.rb
class does a simple mapping of request URL to some request variables.
These request variables include :controller and :action to map to the
controller class and the action method respectively. You can override
this default mapping. The process is to override the
Routing.Routes.draw static method to add the different route mappings.
The defaults here are:
map.connect ':controller/service.wsdl', :action => 'wsdl'
map.connect ':controller/:action/:id', :defaults => { :action =>
"index", :id => nul }
Essentially, the first parameter has the names of the map entries (the
items with ':' in front) that match the item in the URL prototype,
followed by any additional names we want to set up. The defaults map
entry which in turn holds another map of entries that will be used if
there is no match. For example, with these wiring approaches the
following will be true:
URL: foo/service.wsdl
maps to: controller = "foo_controller", action = "wsdl"
URL: bar
maps to: controller = "bar_controller", action = "index", id = nil
URL: bar/baz
maps to: controller = "bar_controller", action = "baz", id = nul
URL: bar/baz/1
maps to: controller = "bar_controller", action = "baz", id = 1
This is actually not a bad approach. Essentially you get some fancy URL
rewriting that sets up your environment for you. There are two required
entries for any wiring to work which are the controller and the action.
Everything else is ad-hoc, although the id is an encouraged (and in many
cases expected) idiom.
We are not limited to the defaults either. We have the ability to
specify regular expressions to validate URL bits.
The additional item here is more of a Ruby idiom in that the ":name"
approach is that we are specifying a symbol which is a predefined
object. It would be analogous to us specifying some enumerations for
the entries in the router.
All that I am putting forth here is that this is a mechanism that can be
powerful to extend and use for our own purposes.
Re: The real Processor concerns
Carsten Ziegeler wrote: Berin Loritsch wrote: The only thing that needs the getComponentConfigurations() method is the DefaultSitemapConfigurationHolder. We need a new interface to support that contract. Not all processors need to use that. Actually the current getComponentConfigurations() is used for passing per sitemap configurations to components. Now with 2.2 we can have a configuration file next to the sitemap. So by moving the configuration into the xconf file we can forget about this completly. The only problem I see is that this is an incompatible change. But appart from that I think we really should get rid of this feature completly. There is nothing that says what its purpose is in the JavaDocs, so its hard to say. I based all my observations from the "Find Usages..." option in IDEA. I do agree that the configurations should be moved outside of the sitemap though. In all reality, it is very rare that you would change a component's configuration. The only time I can think of is when you are defining an Action, but then again a properly defined one will respond to information passed in as the item is being used.
Re: Concern Creep on the Processor interface
Carsten Ziegeler wrote: As a short answer: yes, the interface is ugly - but on the other hand we only have one implementation and could remove the interface and directly interact with the tree processor :) The reason is more or less a historical one. We needed a clean implementation for the tree processor and used the fastest approach. For example the internal class is used to pass all relevant information back to the client in order to release everything properly. This mechanism was very ugly and not always working in 2.1.x. And out of similar reasons I guess more and more was added without really be interested in having a clean Processor interface. So, if we can clean it up, yes - but we must take care that resources and memory are released in a proper and direct way. And now I am trying to implement a new one, and there is all this cruft I don't need in there. I just want to boil it down to what is important to my needs.
The real Processor concerns
Based on the calls from the whole of Cocoon, the core Processor
Interface is:
interface Processor
{
InternalPipelineDescription buildPipeline(Environment env);
boolean process(Environment env);
}
(Note: I would separate out the InternalPipelineDescription object into
its own class)
Who calls these methods?
* the core Cocoon object
* the CocoonWrapper object
* The BlocksManager(s) objects
The getContext() method is used by the BlockManager(s) objects and the
CocoonSourceResolver to identify the URL context we are resolving. I'd
lean towards a separate interface, but at this point I'm not completely
against it in the Processor interface. Although, I'm still thinking it
can be handled outside the Processor. See below about the
SourceResolver. I'm thinking the whole URI management should be done
externally to the Processor. The Processor implementation should be
blissfully unaware of where it is installed.
The only thing that needs the getComponentConfigurations() method is the
DefaultSitemapConfigurationHolder.
We need a new interface to support that contract. Not all processors
need to use that.
The Pipeline implementations need a contract or an external mechanism to
get the SourceResolver corresponding to a Processor. In my oppinion,
the SourceResolver heirarchy should be handled outside the Processor
itself. That's my oppinion though.
The getRootProcessor() is called by the SitemapSource object--again, the
same processor to URL heirarchy should be managed in an external mechanism.
All the attribute methods (set/get/remove) are strictly TreeProcessor
specific. There is no real reason for them to be part of the core
Processor interface. I think we can safely move them without causing
issues. The only other time the Attribute method is used is in the Core
class to get an Interpreter--and we even ignore the language for now.
In what way is the Interpreter important to the Core? In fact it is not
even called outside of the implementing method.
Concern Creep on the Processor interface
The Processor interface used to be very simple, and reasonably
documented. Over time it has adopted new methods as part of its
contract, and those have not been well documented. The only reason that
I am bringing this up is that I am trying to implement my own Processor,
and there is a lot that the interface requires that is of little or no
concern to me. First lets see what it used to be 2 years and 7 months ago:
interface Processor
{
boolean process(Environment env) throws Exception;
// the remaining methods were introduced in 2.1
ProcessingPipeline processInternal(Environment env) throws Exception;
Configuration getComponentConfigurations();
}
Already we see we added some scope creep from the 2.0 to the 2.1 series
(the last I worked on Cocoon was the 2.0 series). For example, why is
it necessary for a Processor contract to expose the component
configurations? The "processInternal" method is a coin toss.
Presumably it is to enable cocoon:// or sitemap:// psuedo-protocols to
be more consistent--allowing a parent processor to call
processInternal() on child processors. Nevertheless, one would wonder
why the original process() method wasn't changed to return a
ProcessingPipeline instead of a boolean in this case.
At this point I also want to point out that the original process()
method has decent JavaDocs so that you can understand its purpose and
why it exists, the remaining methods are not that way.
A month later the getComponentConfigurations() method was refactored to
return a Map--presumably of component Configuration objects, but there
is still no documentation on what the expected keys are.
Three months later processInternal was changed to buildPipline (same
arguments and return value)--a better picture but still nothing in the
JavaDocs to help understand the method purpose.
Two months later we add the Processor getRootProcessor() method to
support internal redirects. Now this is one thing that makes Processors
much more difficult to implement. Why can't such a thing be handled by
a ProcessorHelper or something. The root processor problem is
orthagonal to the responsibilities of just one processor.
16 months, 2 weeks ago we had the biggest change to the whole
interface. We have an interface with an internal class?! The
InternalPipelineDescription has a reason for existing, I'm sure.
However I do have to wonder why it is part of the interface. At this
point we are specifying implementation details in the interface. The
contract of the Processor is no longer an active component (i.e. I tell
you how to do something), but a passive one (i.e. I ask you how to do
stuff for myself). The buildPipeline() method is now altered to use the
InternalPipelineDescription instead of return a ProcessingPipeline. At
the same time we add the getContext() and getSourceResolver() methods.
My head is now realing. This is pure insanity. Why not just get rid of
the interface and simply use a base class? After all we are no longer
documenting a contract, we are documenting how to implement the
Processor. My guess is that limitations in the TreeProcessor approach
caused this to be necessary. But again, couldn't most of these things
have been handled by an external helper or utility class? Does it
really need to affect the interface?
11 months, 3 weeks ago we refactored the getComponentConfigurations()
again so that we now have just an array of configurations. Not a biggy,
but I'm still not convinced it is needed here.
3 months ago we have the last change to the Processor interface, and I
am convinced this should have been a TreeProcessor interface that
extends the core Processor interface. We added methods for setting,
getting, and removing attributes for the sitemap interpreters.
The bottom line is that we have exploded the complexity of what was
originally intended to be a light-weight interface. The only solution
for the processor is a complex solution. The only implementation for a
processor is the tree processor. We've made sure that the interface
requires it to be that way. I've got much simpler needs, and there is a
whole host of issues with implementing all these methods that do
nothing. I'd like to see if we can't separate all the different
concerns in the Processor interface into multiple interfaces. What is
the core concerns?
I'm in the process of identifying the real contracts, and I'll have
another post about that.
Re: svn commit: r312725 - in /cocoon/blocks/crails: ./ trunk/ trunk/WEB-INF/ trunk/java/ trunk/java/org/ trunk/java/org/apache/ trunk/java/org/apache/cocoon/ trunk/java/org/apache/cocoon/controller/ t
Upayavira wrote: Berin Loritsch wrote: Where is whiteboard? https://svn.apache.org/repos/asf/cocoon/whiteboard/ Create yourself a directory there. Will do.
Re: svn commit: r312725 - in /cocoon/blocks/crails: ./ trunk/ trunk/WEB-INF/ trunk/java/ trunk/java/org/ trunk/java/org/apache/ trunk/java/org/apache/cocoon/ trunk/java/org/apache/cocoon/controller/ t
Upayavira wrote: [EMAIL PROTECTED] wrote: Author: bloritsch Date: Mon Oct 10 12:56:04 2005 New Revision: 312725 URL: http://svn.apache.org/viewcvs?rev=312725&view=rev Log: starting to flesh out my ideas--they are better seen rather than discussed Added: cocoon/blocks/crails/ cocoon/blocks/crails/trunk/ cocoon/blocks/crails/trunk/WEB-INF/ cocoon/blocks/crails/trunk/java/ cocoon/blocks/crails/trunk/java/org/ cocoon/blocks/crails/trunk/java/org/apache/ cocoon/blocks/crails/trunk/java/org/apache/cocoon/ cocoon/blocks/crails/trunk/java/org/apache/cocoon/controller/ cocoon/blocks/crails/trunk/java/org/apache/cocoon/controller/BaseController.java cocoon/blocks/crails/trunk/pom.xml cocoon/blocks/crails/trunk/samples/ Could you please move this to the whiteboard, rather than a new block? Generally blocks need voting in before they are created, as they do add to the baggage that Cocoon carries. Maybe when we have blocks more developed we can change this, but, at the moment, creating a new block gives the wrong impression, IMO. Otherwise, I'm interested to see what ideas you have. Regards, Upayavira Where is whiteboard?
Re: Reality Check (was Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK))
Torsten Curdt wrote:
My major complaint against flowscript isn't the concept--its the
feeling that I am flying without a net. I don't have a convenient
way of testing the javascript. I can't use an IDE to make things
even easier. There is something to be said for using the
autocomplete function of your favorite IDE as apposed to trying to
remember how everything is mapped to the FOM.
Well, then use javaflow :)
I still feel that flow is not the right tool for the simple mapping of
action to view. It might be worth it to take a little time, play with
Rails to get a feel for it. Imagine the following scenario workin in Java:
class ApplicationController extends BaseController // a Sitemap
implementation
{
// override the default layout for this application
protected String layout = "mysite";
protected boolean shouldSayHello()
{
return Random.nextBoolean();
}
}
class hello_controller extends ApplicationController
{
public void index(FOM context) // note FOM is not a type, but the equiv.
{
// the default--fall through
}
public void hello(FOM context)
{
// This attribute is now ready for the view
FOM.request.setAttribute("hello", "world");
}
public void redirectToController(FOM context)
{
// The first parameter is the controller, the second parameter
is the action
sendPage("othercontroller", "index");
}
public void redirectToActionOnCondition(FOM context)
{
String action = shouldSayHello() ? "hello" : "index";
sendPage(action);
}
}
We have done a few simple but powerful things here:
* We have one location to update the layout of all the
controllers--although an individual controller can override it if they want
* The method does any setup necessary, and then the system just "falls
through" to the corresponding source file.
* All we need to do to add a new action is implement a method.
* We still have the "redirect" ability if we want to send a specific
page (i.e. the sendPage()) method inherited from the base class.
* We also have a way to add methods available to all the application's
controllers in the ApplicationController base class using the protected
methods.
All of these take advantage of the world we already know without having
to learn something new. It provides some convenient method of extention.
Re: Reality Check (was Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK))
Max Pfingsthorn wrote:
The "handleControllerCall" function can be written in flowscript or even use
the great new java flow as shown by Torsten Curdt during the get together. Not sure how
that class reloading works, but if you put the controller classes in the same path, I
guess the reloading feature would work there as well. So, you can do something like...:
if(action==null) action="index";
contr =
Package.org.apache.cocoon.util.ClassUtils.newInstance("controllers."+controller+"Controller");
if(id==null)
contr[action]();
else
contr[action](id); //well, a little more processing here to get the object
with this id first
cocoon.sendPage("views/"+controller+"/"+action);
Right?
max
One of the nice features of the Rails implementation is the fact that a
class method maps to an action. It makes the code very easy to test,
and therefore very appealing.
Think about it, if you were going to write a unit test, would you rather
invoke a scripting engine or simply execute against a class?
Also, the inherent simplicity of concepts where a developer can leverage
the Java skills that they already have is very enticing. The controller
would essentially inherit a base class that takes care of the reflective
resolution of the actions, and all is well. It just works. My major
complaint against flowscript isn't the concept--its the feeling that I
am flying without a net. I don't have a convenient way of testing the
javascript. I can't use an IDE to make things even easier. There is
something to be said for using the autocomplete function of your
favorite IDE as apposed to trying to remember how everything is mapped
to the FOM.
Again, why should the developer have to type out cocoon.sendPage(...)
when the sitemap implementation takes care of it for you.
Reality Check (was Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK))
In this thread, we have the perfect example both of what makes Cocoon great and its own achiles heel. The initial proposal here was to make a new type of sitemap that mimics the Ruby on Rails pattern of Convention over Configuration. It even had some nice approaches to flexing some of Cocoon's strengths with the improved layout code. I purposely skipped over the details of the model approach becuase it is a whole can of worms that can be better tackled later. What happened is that some of our faithful Cocooner's saw the missing piece in the proposal and started discussing how to fix it, and are getting into alot of detail. The problem is that the same quotes from Anonio's presentation are being forgotten: "Simplicity is the ultimate sophistication" Leonardo da Vinci (my personal favorite) "Everything should be made as simple as possible, but not simpler." Albert Einstein "Out of intense complexities intense simplicities emerge." Winston Churchill To be honest, I am not happy with any of the Java Object to Relational Database binding libraries out there. However, it is not the problem to focus on at this juncture. The first part is to get the convention working for the new sitemap implementation. After that, we can start tackling the more difficult aspects of the framework simplification. In the Java world, everyone has their favorite database abstraction. Why do we need to force the user's hand at this time? Let's worry less about perfection and worry more about some simple changes that have huge payoffs. Once we have the basics down, we can tackle some of the more difficult aspects.
Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Andrew Savory wrote: In all seriousness, the biggest lesson from the Ruby on Rails project that Cocoon can learn is the power of convention. One of the biggest things that contributes to the high learning curve of Cocoon is the lack of convention. Not just the lack of convention but also the lack of good sample apps (solved by Bertrand with the bricks-cms) and of a decent generator of templates (temporarily done by raccoon but hopefully soon by m2 archetypes). This morning I asked if Cocoon is too complex for convention, or if we simply have a logistical problem - lack of time to define suitable conventions. It looks like you've given us a starting point! Its largely a lack of knowing where to start. As to the sample apps--I agree to a point. If you don't have the convention to build the sample app with, how is the potential user going to know what they are looking at? In other words what are they going to walk away with when the look at a sample app? Model - The Rails model is one of the most powerful aspects of the whole framework. I'm not going to go into the whole ActiveModel architecture other than to say that the model lives in the app/ models/ directory and the class name is the singular form of the concept (i.e. LogEntry) and the backing database table is the plural form (i.e. LogEntries). Using convention to map class methods to tables and records is a very powerful aspect that beats out anything else in the Java world. It would be a project in and of itself to write a replacement for this piece--which is not something I would recommend for CRACK. I got a little way down this path using XSLT and the SQLTransformer (crude but it worked). We can go a long way using JDBI (http:// jdbi.codehaus.org/) and DdlUtils (http://db.apache.org/ddlutils/). Hopefully Sylvain will be able to commit his JDBI flowscript wrapper as a start. SQLTransformer is evil (it should have been deprecated and done away with back in the early 2.0 days). Again, its mixing the concerns. A proper model is a separate entity that can be easily referenced, modified and controlled through the controller and then examined from the view. It should not be mixed in with the view. View In the CRACK version matching the /login/index URL, we would look for (in this order) a .jx file, a .xml file, or a .xsp file that matches the name of the action "index". More clearly, in that example CRACK would look for app/views/login/index.jx first, and then substitute the other extensions in case they are there. The Rails view framework also allows fragments that can be embedded in other views, but this is good enough for now. I think views are one of the areas where RoR is the weakest, and where we can make the most significant improvements - for example thinking in terms of a CRACK view being index.jx/xml coupled with an associated xslt by default. Amazingly, it is good enough for many uses. I like the simplicity of being able to specify the JXL as the generator portion and then finishing the pipeline with the layout. "It just works" for the 80/20 rule. Changes to Cocoon - In order to support something like this, we don't have to make fundamental changes to Cocoon. In fact, all we have to do is provide an alternate Sitemap implementation that uses reflection to find the controller class and build the pipeline based on the view source, the layout location, etc. Or a tool to one side of core Cocoon that provides these features, and can also generate the default layout etc? When the base convention is defined, it is easy to add the code automation scripts to support that convention. Again, reasonable defaults also help. That allows the user to concentrate on one thing at a time.
Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Andrew Savory wrote: Hi Berin, On 7 Oct 2005, at 15:09, Berin Loritsch wrote: Here's the deal: Cocoon is a very powerful publishing framework adapted to do web applications, and Ruby on Rails is a very empowering web application framework that can be adapted for a number of purposes. There are two very different mindsets behind the two frameworks--and I believe we can leverage the very potent lessons learned from Rails for the Cocoon framework. I couldn't agree more. In fact, I spoke about this at the GT this morning :-) The full slides with notes, videos etc will be available via the GT web site shortly, but until then you can see the basics at http:// www.luminas.co.uk/andrew/raccoon.pdf Your SHRT goes into rather more technical detail than I managed. Hopefully it can produce some more conversation topics at the GT. I saw the PDF, but without the comments or extra talking points its hard to get much out of it. I.e. the questions are asked, some great quotes (and a really nice looking presentation), but no content to walk away with. Hopefully that can be added in later. As to the technical detail, I've used Rails and I've used Cocoon--I know where things can happen. Its possible and it can/should be done.
[SHRT] Cocoon on Rails Application Component Kernel (CRACK)
SHRT = Semi-Humorous Random Thought
Here's the deal: Cocoon is a very powerful publishing framework adapted
to do web applications, and Ruby on Rails is a very empowering web
application framework that can be adapted for a number of purposes.
There are two very different mindsets behind the two frameworks--and I
believe we can leverage the very potent lessons learned from Rails for
the Cocoon framework. The only real humorous aspect of this post is the
acronym I came up with above. In one summary statement:
CRACK: A highly adictive web framework that is very potent. Side
affects include loss of weight, faster completion, and eagerness for
more. Best selling point: seeing the reaction of saying your a "CRACK Ho".
In all seriousness, the biggest lesson from the Ruby on Rails project
that Cocoon can learn is the power of convention. One of the biggest
things that contributes to the high learning curve of Cocoon is the lack
of convention. Because there are so many ways of doing things, the user
has to learn all of them to determine what is going to be best for the
project the user is working on. I belive that this lack of convention
is even a bigger contributor than all the different XML standards that
we integrate. A long time ago Stefano gave the RT on the URL as a
contract--and rightly so. The Sitemap was born of that RT allowing
Cocoon to respect the external contract and the developer to organize
the filesystem any way they chose. The Rails solution to the problem is
the convention of the MVC architecture is also mapped in a logical way
to the files and class structure. Let me lay out the convention used:
Controller
--
Rails has a definite mapping of the URL to a controller. The convention
is {context}/{controller}/{action}[/{id}] where {context} is the
location where the app is running, {controller} is the controller class
that responds to actions, {action} is the method on the controller class
that is called to process a request, and {id} is an optional piece that
identifies a specific record. The controller class is defined in the
app/controllers/ directory and has a naming convention of
{name}Controller. For example a "Login" controller would be named
"LoginController". Rails finds the controller based on the URL. Once
Rails has the controller it calls the method matching the action. One
of the side effects is that the URL does not have any extensions defined
(i.e. there is no .html or .pdf in the URL). The job of the controller
is to do any set up for the request before it allows the action to "fall
through" to the matching view.
Model
-
The Rails model is one of the most powerful aspects of the whole
framework. I'm not going to go into the whole ActiveModel architecture
other than to say that the model lives in the app/models/ directory and
the class name is the singular form of the concept (i.e. LogEntry) and
the backing database table is the plural form (i.e. LogEntries). Using
convention to map class methods to tables and records is a very powerful
aspect that beats out anything else in the Java world. It would be a
project in and of itself to write a replacement for this piece--which is
not something I would recommend for CRACK.
View
The Rails view lives in app/views/{controller}/{action}. That's right,
there is a mapping of a set of views directly 1:1 to the controllers.
In the case of the LoginController there would be an app/views/login/
directory, and for each action ("index", "login" etc.) there would be a
view that corresponds. In the Ruby on Rails world these are .rhtml
files so they are analogous to XSP or JXL files. In fact I would argue
that it is closer to JXL than XSP. Once the method in the controller is
complete, provided the controller did not explicitly send a named page,
the view is selected from this directory. In the CRACK version matching
the /login/index URL, we would look for (in this order) a .jx file, a
.xml file, or a .xsp file that matches the name of the action "index".
More clearly, in that example CRACK would look for
app/views/login/index.jx first, and then substitute the other extensions
in case they are there. The Rails view framework also allows fragments
that can be embedded in other views, but this is good enough for now.
Now, imagine a Cocoon scenario where the user is faced with a blank
project. Where to begin... Using the power of convention, they start
writing a class named HelloController.java located in the
app/controllers/ directory. They add one method called index() to the
class. Then they open the browser to
http://localhost:8000/cocoon/hello--at which point Cocoon compiles the
HelloController.java class and responds by processing the index() method
(oh yeah, forgot to mention the convention of the index method being the
default for any controller). The user sees an error message saying that
the view app/views/hello/index.j
Problem with ESQL and Unicode
Using ESQL against MSSQL Server, any NTEXT or NVARCHAR are incorrectly re-encoded to ISO 8859. Directly using the driver yields the correct results.
Re: [Docs] Copy/Move all reference docs about sitemap components into Daisy
hepabolu wrote: Berin Loritsch wrote: hepabolu wrote: Guys, I feel that Daisy should be the source for all documentation about Cocoon (at least for now), so I'll be copying over the reference documentation of all sitemap components, as they are currently defined in the Javadocs of the respective classes, to Daisy. Please indicate if there are some components that are obsolete or on the verge of being deprecated, to reduce the amount of superfluous work. Bye, Helma I already have a whole section on developing Cocoon components up on daisy--please make sure it is not a rehash. I don't think so. You wrote about actual development, my intention is to provide a kind of reference of what's already there. Sounds good. Thanks.
Re: [Docs] Copy/Move all reference docs about sitemap components into Daisy
hepabolu wrote: Guys, I feel that Daisy should be the source for all documentation about Cocoon (at least for now), so I'll be copying over the reference documentation of all sitemap components, as they are currently defined in the Javadocs of the respective classes, to Daisy. Please indicate if there are some components that are obsolete or on the verge of being deprecated, to reduce the amount of superfluous work. Bye, Helma I already have a whole section on developing Cocoon components up on daisy--please make sure it is not a rehash.
Re: [RT] seven good reasons to close down users@cocoon.apache.org
Bertrand Delacretaz wrote: Le 3 oct. 05, à 22:56, Mark Lundquist a écrit : ...But please don't use the term "close down", instead say "merge" or "consolidate" :-) You're right, of course, "merge" is much more appropriate. -Bertrand Before going too far with this proposal, consider the impact of Stefano's latest thread on the average user. Esp. in light of the fact that there are several more people who simply lurk than who actually participate.
Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)
Sylvain Wallez wrote: Interesting question. If we ship with dev mode on, many people will deploy in dev mode. On the other hand, if we ship in production mode, many people won't see the features of dev mode. A solution is to ship in dev mode, but ensure that people know they're in dev mode. With a big splash, either in the console, in a transient Swing window (appear for 5 seconds and disappear) or why not as the first page displayed in the browser. The Ruby on Rails solution is to use an environment variable that defaulted to "Development". In production the environment variable would be set on the server to "Production". For the unit tests, the generators automatically run in "Test" mode. Now, I know that Java 5 has the re-introduction of environment variables, and we still need Java 1.4 support--so some sort of equivalent would be decent. The solution works amazingly well.
Re: [RT] Is Cocoon Obsolete?
Sylvain Wallez wrote: Kewl! If it's based on the 2.2 branch, you may reduce startup time by adding JAVA_OPTIONS="-Dorg.apache.cocoon.core.LazyMode=true" in the launch script (BTW, should we make this the default?) IMO Yes. Anything that helps us work more efficiently should be default.
Re: [RT] Is Cocoon Obsolete?
Very interesting read. As with all inovations, the greatest achievements are usually the "side issues". The SoC, component frameworks, et al, helped improve the way we think about approaching the development of software. While that has little to do with web publication, the contributions to the development world are certainly there. However, I do disagree in one area (see below) Stefano Mazzocchi wrote: If you ask me, the current infatuation with Ruby on Rails and friends, while understanding and to the point (the need to avoid XML pushups, so true), will fail dramatically short in scale to complex systems. Just like M$ Word is great to write one/two pages and it fails miserably to help you with your thesis, something like rails is awesome for your blog or single-handed ecommerce web site, it would kill you no less than PHP with a massively complex web site. I'll be honest that I am currently infatuated with Ruby and Ruby on Rails in particular, but it is more the way that they approach the problem of writing a web application. The contribution is the simplicity and power of convention over configuration. Think about it, all the reams of paper that the Cocoon configuration files and Sitemaps take up in XML are largely unnecessary in the Rails world because there is an intelligent default behavior. Just like Cocoon, the overarching principle of design behind that framework improves the development world. We may be reading something like your post about Rails in the future, nevertheless the underpinning design mindset can influence the process of writing great software. Truth be told, I am less convinced about Mozilla as a platform than I am about either Cocoon or Rails. I don't doubt there is great power that the browser gives the developer and the user, but at the same time there is even less to help the poor newbie get emersed into that world. When I see a coherent Mozilla development environment I may change my mind. As of right now, there are new possibilities but the barrier of entry is still too high for the Mozilla as a platform.
Re: RequestParseException?
Torsten Curdt wrote:
/Users/tcurdt/dev/cocoon-trunk/src/java/org/apache/cocoon/generation/
RequestGenerator.java:233: cannot resolve symbol
symbol : class RequestParseException
location: class org.apache.cocoon.generation.RequestGenerator
throw new RequestParseException("Could not parse the
parameters.", e);
...forgot to add it?
I realized I forgot to add it, did the "svn add" and forgot to commit
it. It should be there now. My appologies
FYI New Exception thrown (was Re: svn commit: r292770 - in /cocoon/trunk/src/java/org/apache/cocoon/i18n: XMLResourceBundleFactory.java XMLResourceBundleNotFoundException.java)
FYI:
I changed the "FIXME" comment that had a question with a runtime
exception. This should answer the question quite well. Before we
simply ignored XMLBundles with no base URL--now we force the system to
deal with it. It should also help tighten up some code.
[EMAIL PROTECTED] wrote:
@@ -371,10 +370,11 @@
protected String getFileName(String base, String name, Locale locale) {
StringBuffer sb = new StringBuffer();
if (base == null || base.length() == 0) {
-// FIXME (SW): can this happen?
+throw new IllegalArgumentException("'base' cannot be empty or
null.");
Re: NotImplementedException vs UnsupportedOperationException
Reinhard Poetz wrote: Out of curiousity, is there any special reason not to take the UnsupportedOperationException instead? Not a major one. Precedence has already been set in another part of the Cocoon code base, so I carried it forward. There is also a distinction between something that is not supported and one that is simply not implemented. In one case you may have a method because the interface implemented requires that the method exists, but your implementation is never going to support that method--case and point would be a read only collection, all write methods would throw UnsupportedOperationException. In this case, we do want to have it as a flag that we have some work to do. So yes, we want to get rid of all NotImplementedExceptions but we want to do it by implementing the methods that need implementing. Using the UnsupportedOperationException should be done for methods that will never be supported in an implementation. btw, I really like your exception renaming effort! Thanks. Hopefully it pays off with troubleshooting.
[RT] Smarter Use of Exceptions
Based on the errors from the Java 1.3 compatability issues I decided to
check how pervasive the use of generic runtime exceptions was. I am
quite surprised at the results. It seems that instead of having planned
and known exceptions we opt to throw generic exceptions all over the
place. Attached to this is a grep of the current source code searching
for the phrase "throw.*RuntimeException" to show just how pervasive the
use of generic exceptions.
Before I dive into more detail here, I am not questioning the use of
unchecked exceptions. I am challenging the use of _generic_
exceptions. I am also lumping the CascadingRuntimeException, and
CascadingException in the generic exception category. The exception
type tells you nothing that you didn't already know... that something
exceptional happened. We have five hundred and three places where we
throw generic runtime exceptions.
In general it is good practice to throw a typed exception than a generic
one. You have a much better idea of the problem when you see
ValidatorInitializationException as opposed to RuntimeException. The
very name of the exception provides a clue as to what can happen and
where. The fact that you have an exception class that you created also
signifies the fact that the exception was planned and it didn't just
happen somewhere in the bowels of the JVM. The same argument goes for
your generic Exception and CascadingException. It is better to throw a
specific exception than it is to throw a generic exception. The more
specific you are, the more likely you will be able to narrow down on the
problem--and the less doubt you will have about the system as a whole.
Creating a new exception class is not difficult, you just have to do
it. Using the example comparison in the above paragraph we can create
our ValidatorInitializationException with just a few lines of code:
public final class ValidatorInitializationException extends RuntimeException
{
public ValidatorInitializationException(String message)
{
super(message);
}
}
If you want a constructor that wraps another exception and is compatible
with Java 1.3, then it is also simple to do:
public vinal class ValidatorInitializationException extends
CascadingRuntimeException
{
public ValidatorInitializationException(String message)
{
super(message);
}
public ValidatorInitializationException(String message, Throwable cause)
{
super(message, cause);
}
}
Given the ease of which we can create exceptions with more semantic
meaning we should start doing that. Just to drive home the point,
imagine your significant other's car broke down and they are off the
beaten path. The problem is that there is a seven way intersection
between you and your loved one (and yes there is such a thing as a seven
way intersection). If your loved one says that they are by some houses
down the street, you will have a tough time finding them. If your loved
one says that they are by house 315 on Orchard Street, then you stand a
much better chance of finding them quickly. That is the difference
between generic exceptions and typed exceptions. While there is no
programatic advantage to writing a new class that does nothing more than
extend a base class, there is a semantic advantage so that when you see
your error page you can zoom in much more quickly.
Now, I'm only one guy so me making 305 changes with only a surface
understanding of why each of those exceptions is thrown doesn't scale
very well. It would make much better sense if we all got on board and
improved the blocks and modules we are working on ourselves. But as a
general rule for new development, it should be a problem when the phrase
"throw new RuntimeException" is encountered in new code. Why was it
thrown? Was there a checked exception that could have been thrown
instead? How can we find the cause quickly without getting lost in the
stack trace? BTW, the only part of the stack trace that is important is
the one to the original causal exception. Are we losing the original
exception? Many of these questions can be avoided when we have a known
exception to throw. If you want it to be checked or unchecked is up to
you and your personal beliefs. However, generic exceptions are evil.
I've had to try to track down where problems are in several systems and
the use of the generic exception only made the bug fixing worse.
rteclasses.log.gz
Description: GNU Zip compressed data
Re: forms block does not compile for java 1.3
Antonio Gallardo wrote: Ralph Goers wrote: I guess this means forms trunk has to support JDK 1.3 and cannot move to 1.4? Yep, since we are now sharing the same form block (in cocoon-blocks) for both cocoon versions (2.1.x and 2.2). Seems like every day JDK 1.3 compatibility becomes a bigger PITA! :-( Need we still care? In the case of the RuntimeExceptions, if we have our own exception class that extends RuntimeException and supports the necessary constructor we effectively accomplish two things: 1) We can support any version of Java 2) We have a much better clue of where the runtime exception came from--it is essentially branded.
Re: forms block does not compile for java 1.3
Antonio Gallardo wrote:
Hi:
Here is the output:
Compiling 330 source files to
/home/agallardo/svn/cocoon-2.1/build/cocoon-2.1.8-dev/blocks/forms/dest
/home/agallardo/svn/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/library/Library.java:118:
cannot resolve symbol
symbol : method split (java.lang.String)
location: class java.lang.String
String[] parts = key.split(SEPARATOR);
^
Ok, this is a new feature for the String class in Java 5. Doesn't
Cocoon have a StringUtil class to split stuff like that?
/home/agallardo/svn/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/library/Library.java:56:
cannot resolve symbol
symbol : constructor RuntimeException
(java.lang.String,org.apache.avalon.framework.service.ServiceException)
location: class java.lang.RuntimeException
throw new RuntimeException("Could not
initialize Library, LibraryManager not found!",e);
^
There are two issues here:
1) The fact that the library is throwing an untyped RuntimeException.
If throwing a RuntimeException is absolutely necessary, please have the
decency to throw a subclass such as a LibraryInitializationException or
something similar.
2) The constructor for the RuntimeException that accepts a root-cause
exception was introduced in Java 1.4.
FOP and Cocoon URL question
I can't seem to reference a graphic in my FO document to be included in my PDF document. The problem is that the graphic is generated on the fly--and only really accessible through a "cocoon" URL. I can't seem to make it work, and I can't seem to find any documentation to help me on my way. Can anyone lend a hand?
Re: [RT] Replace excalibur-io with commons-io
Torsten Curdt wrote: On 06.09.2005, at 04:23, Antonio Gallardo wrote: Hi: Recently on excalibur dev I found that most (if not all) the code in excalibur-io was moved to commons-io: http://www.mail-archive.com/dev%40excalibur.apache.org/msg01599.html Cocoon 2.1.x has only 3 references to exclaibur-io. They can be easily switched to commons-io. Some other goodies: 1-Some of the methods in o.a.c.utils can be switched to commons-io 2-Lenya distribute commons-io as an additional jar. WDYT? Sounds like a good idea ...IMO +1 That was the intent--all of excalibur-io is included in commons-io now
Writing a transformer available
http://cocoon.zones.apache.org/daisy/documentation/writing/sitemapcomponents/694.html Really simple transformer example as most people aren't going to write their own transformers anyway.
[Fwd: Adapted Sylvain's WritingForCacheEfficiency]
Sent to the wrong mail list... sorry --- Begin Message --- Sylvain, since you provided the source information, can you make sure I didn't interject anything wrong? The URL for the writeup is here: http://cocoon.zones.apache.org/daisy/documentation/writing/690.html I have yet to work on the transformer component, but we almost have the full gammut covered for the core items. When we have real blocks I'll have to do a similar writup for that. --- End Message ---
Adapted Sylvain's WritingForCacheEfficiency
Sylvain, since you provided the source information, can you make sure I didn't interject anything wrong? The URL for the writeup is here: http://cocoon.zones.apache.org/daisy/documentation/writing/690.html I have yet to work on the transformer component, but we almost have the full gammut covered for the core items. When we have real blocks I'll have to do a similar writup for that.
Re: Serious bug in tree processor
Carsten Ziegeler wrote: Berin Loritsch wrote: Anybody know what the root issue is? The type attribute of the pipeline element has not been evaluated correctly. In this case the type attribute of the first pipeline element has been used for all pipeline elements in a sitemap. Do we have a TestCase to catch the problem in case it is accidentally re-introduced? I don't think so. The test case should have at least to pipeline sections with different type attributes and should test if the correct pipeline is used in each section. And it's already fixed? Hmm. That does make it hard to validate a test case. I'm terribly busy right now (I've got a meeting downtown in a few minutes), but I might be able to get a testcase in there to ensure we don't fall into this again. What was the revision with the error in tact? I'll try to get to it later today.
Re: Serious bug in tree processor
Reinhard Poetz wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: Perhaps this is as well the cause of Reinhard's problem wrt caching. I will check this weekend or next week. Thanks! Caching works for me again now :-) Anybody know what the root issue is? Do we have a TestCase to catch the problem in case it is accidentally re-introduced?
I took the liberty of updating the JavaDocs on the core components
Alot of the information I documented really should have been part of the JavaDocs all along. I took the liberty of adapting what I wrote on daisy to the JavaDoc format. Even though there is a large amount of duplication now between the two resources, I still think that there is value in the documentation in daisy. The main reason being the fact that it is gathered all into one place. In the process, I did find an omission in the docs I wrote. I'll see about adapting the "Writing for Cache Performance" that Sylvain wrote.
Creating a Generator completed
This is one that I think could use a second pair of eyes to make it more understandable. The URL is here: http://cocoon.zones.apache.org/daisy/documentation/writing/sitemapcomponents/688.html I also had to introduce the XML Pipeline contracts documentation here: http://cocoon.zones.apache.org/daisy/documentation/writing/corecontracts/689.html Now this is something where the JavaDocs should be updated to reflect it.
Re: Another sitemap component HOWTO ready
Tony Collen wrote: Berin Loritsch wrote: This will be my last installment before I go on vacation next week. The earliest I can get to the Generator, Transformer, and Serializer components will be after Sept. 5. Enjoy +1, excellent writeup!!! Very good quality.. keep it up! :) Thanks for the encouragement, expect more after I get back.
Another sitemap component HOWTO ready
How to Create a Reader: http://cocoon.zones.apache.org/daisy/documentation/components/sitemapcomponents/681.html I hope others proof what I've written because it is largely based on a combination of memory and implementation details as I update my knowlege base. I want to make sure I'm not disseminating anything patently false. This will be my last installment before I go on vacation next week. The earliest I can get to the Generator, Transformer, and Serializer components will be after Sept. 5. Enjoy
Re: wget Cocoon BRANCH 2.1.x?
Emmanouil Batsis wrote: On Friday 19 August 2005 18:01, Upayavira wrote: Do you have a hosted linux server anywhere? Log onto that, do a checkout, make your zip (even build Cocoon with just the blocks you want) zip up whatever is left and download it. Unfortunately the server does not offer SVN and i have no rights to install it :-( wget does crawl, so if you point it to the SVN URL you can get what you want.
Re: Cocoon stacktraces in trunk.
Sylvain Wallez wrote: Hi all, I just committed the Cocoon stacktraces stuff to trunk. There's some more work to be done to throw located exceptions everywhere and reduce exception nesting, but the basic infrastructure is there and is really an improvement compared to what we had a few weeks ago :-) Yay!
Documentation break until next week
I've got the core contracts for the sitemap documented (need some sanity checking there), and documentation for creating a simple Action up and ready for review. You can view it here: http://cocoon.zones.apache.org/daisy/documentation/components/664.html I'm going to have to take a break from it until next week because I have some other things I need to take care of first. Let me know what you think or if there are any improvements to be made.
Core contracts documented on Daisy
http://cocoon.zones.apache.org/daisy/documentation/components/664.html Please note that I am still working on stuff there, but I am taking a break for today. I wanted to cover the really basic root level stuff first so that it is easier to reference that when I get to the higher level documents. Let me know if I'm way off in anything I put down.
Re: [Request] http://cocoon.zones.apache.org/daisy/ Karma
Upayavira wrote: Berin Loritsch wrote: I can't add anything or create a new area for documentation. That means all I can do is view. Kind of hard to contribute like that. As you are down as an (emeritus) cocoon commmitter, I've just given you rights. Look forward to seeing the results of your work! Regards, Upayavira thanks!
[Request] http://cocoon.zones.apache.org/daisy/ Karma
I can't add anything or create a new area for documentation. That means all I can do is view. Kind of hard to contribute like that.
Re: Where are the articles on writing Cocoon components?
Steven Noels wrote: On 13 Aug 2005, at 23:15, Berin Loritsch wrote: It's not that hard to write the Cocoon components, but there should be something that puts it down. I can't guarantee I can do it soon but I'll see what I can do. Where should I put it in the grand scheme of things? If you want, you can register yourself on cocoon.zones.apache.org/daisy. I'm registered, but I can't add documents in any logical place. Its not forms or portal related.
Where are the articles on writing Cocoon components?
It seems that a huge hole in documentation exists on the site. As I was training one of my crew on how to write a reader (adapting a servlet we had) I found I couldn't refer to one nice page. Not even the JavaDocs really help all that much. I didn't even know about the ObjectModelHelper class until I used the class introspector to discover it. I really wanted something that spelled out the entries in the ObjectModel but could not find it. It's not that hard to write the Cocoon components, but there should be something that puts it down. I can't guarantee I can do it soon but I'll see what I can do. Where should I put it in the grand scheme of things?
Where are the articles on writing Cocoon components?
It seems that a huge hole in documentation exists on the site. As I was training one of my crew on how to write a reader (adapting a servlet we had) I found I couldn't refer to one nice page. Not even the JavaDocs really help all that much. I didn't even know about the ObjectModelHelper class until I used the class introspector to discover it. I really wanted something that spelled out the entries in the ObjectModel but could not find it. It's not that hard to write the Cocoon components, but there should be something that puts it down. I can't guarantee I can do it soon but I'll see what I can do. Where should I put it in the grand scheme of things?
