Re: [RT] Simplifying component handling
On Jan 3, 2006, at 9:06 AM, Peter Hunsberger wrote: On 1/3/06, Giacomo Pati [EMAIL PROTECTED] wrote: I'm with Sylvain's and Gianugo's oppinion. I also see users getting confused with multiple choices of how to write a component. I'd say in this area we need a revolution instead of an evolution. I really don't get this objection; if I see a class that allows constructor injection OR can be initialized via some other sequence I'm going to think gee, that's nice, I can do everything in one shot instead of having to call the service manager (or whatever) . All that's required to make sure that's clear is about 2 lines of Javadoc on the constructor and if that's missing and someone does try to initialize the class both ways you can probably make sure it either blows up or handles things gracefully. We use constructor injection in some of our code. It's clean, it's simple, it's easy to write. Sometimes we support multiple methods of initializing the code. It's pretty darn clear what's going on to any user of the code. As a Cocoon user I really think that any objection to this proposal based on it might be confusing to users is bogus... I agree. This is a minor simplification directed towards developers. If they can't figure out when and when not to use this then they need to learn. The fact that this buys you very little is a different concern. Sometimes we spend a bit more then we should for little luxuries, but we're willing to eat bread and water as a result. Just make sure Carsten is the one who suffers for this luxury ;) Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
On Dec 30, 2005, at 4:05 PM, Berin Loritsch wrote: 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. Yes. I think Cocoon could be greatly simplified knowing what we know now. This would be a worthwhile endeavor but not one that should be undertaken at the cost of slowing advancement. Remember Netscape. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
On Dec 30, 2005, at 12:09 PM, Carsten Ziegeler wrote:
Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.
If you look at several of our components, they do something like this:
class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;
public void service(ServiceManager m) {
this.m = m;
compA = (ClassA)m.lookup(ClassA.ROLE);
compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
if ( m != null ) {
m.release(compA);
m.release(compB);
}
}
Way too much code me thinks. So what about:
Come on! how many components do you write a day that 10 lines and 184
characters is too much? Sure less code and fewer interfaces are good
things in general and I don't mind switching to constructor injection
but give me a better reason than you want to write less code.
class MyComponent implements SOMETHING, ThreadSafe {
protected final ClassA compA;
protected final ClassB compB;
public MyComponent(ClassA a, ClassB b) {
compA = a;
compB = b;
}
}
We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of
the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.
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.
I don't like assumptions like this. I see deadlocks in your future.
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).
I make extensive use of the factory pattern and in some instances my
factories use pools. Just because you use factories does not mean you
can eliminate pooling. Now if you'd like to implement self monitoring
pooling that tunes itself I think we'll all be happy.
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?
Now, in the end I really want to write less code :)
sounds lazy to me, but then again I don't want to write any code I
just want to think of something and have it work. :-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
If they can get you asking the wrong questions, they don't have to
worry about answers.
- Thomas Pynchon Gravity's Rainbow
Re: Planning 2.2
On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote: Glen Ezkovich wrote: On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote: Carsten Ziegeler wrote: Now as 2.1.8 is out, we should think about a 2.2 release. I think for a 2.2 release we should at least finish the following things: - Finish the maven2 build - Sync everything with 2.1.x (apply changes that were only applied to 2.1.x if appropriate) - Separate samples from blocks - Remove author tags While imho the first two items on the list are a simple must, I think we should really do the other ones as well. If we don't aim to do them for 2.2 we'll simply never do them. And it's really not that hard to do it. And finally, we should make a stable forms block (and perhaps others as well). WDYT Aren't we aiming at a 2.2M1 release? If yes, the only must is a working build system IMHO. I'm a bit confused, is this the only difference between 2.1 and 2.2 or are the other changes complete and ready to roll? These changes amount to a refactoring. What distinguishes 2.2 from 2.1.8? not at all :-) - ECM++ - Virtual sitemap components - blocks (sitemap blocks, exposing blocks) - per sitemap reloading classloader (for dev) - reworked property management - Spring integration (Spring block) - possible to listen to sitemap events - refactoring of Javaflow (uses now the commons-javaflow project which was started by Thorsten) - introduction of CTemplate (refactoring of JXTemplate in 2.1.x) ... and maybe some other things This is what I thought. I was in effect questioning wether these new features are ready to go. My concern is the documentation for these new changes and features. An admittedly quick perusal of SVN didn't reveal much at all. Even a M1 release requires a bit of documentation so that the changes and new things get tested. We also have the plan that Cocoon 3.0 will be based on blocks that run in a shielded classloader. Currently OSGi ist our best bet (and I'm quite optimistic that it will fit our needs). I'm hoping to see this by the end of next year. As long as I have nothing to do with it it should be doable. Seems like everything I touch these days falls behind schedule. :( Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: Planning 2.2
On Nov 22, 2005, at 5:12 PM, Vadim Gritsenko wrote: Daniel Fagerstrom wrote: Ezkovich Glen wrote: On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote: Glen Ezkovich wrote: ... This is what I thought. I was in effect questioning wether these new features are ready to go. My concern is the documentation for these new changes and features. An admittedly quick perusal of SVN didn't reveal much at all. Even a M1 release requires a bit of documentation so that the changes and new things get tested. First it is an M1 so it is not like that everything have to be completely finished and polished. Second it is a little bit of a chicken and egg problem, as long as we don't start to release the new features, they will feel like a moving target that not is worthwhile to use and document yet. A, where software with market share differs from software without and why cocoon's documentation needs so much work. Documentation is an integral part of a release. It should be developed along side the source code not months after the release. And as long as no one use it and document it we who develop the new stuff doesn't have any presure to stabilize it and stop changing the interfaces. By releasing an M1 we focus the community on 2.2 and hopefully make the things you asking for, happen. Also, while some of the above improvements still are experimental (blocks, virtual sitemap components ...), much of it isn't. ECM++, reloading classloader, refactored JXTemplate, ... really simplifies use of Cocoon, so we should make it available for a larger audience ASAP. Exactly. I agree. But if you release today, then no one except those that have touched those things or followed the developer list will know what those features are much less how to use them. Point me in the right direction, give me a tentative release date and I will write up some documentation. Best offer I can give you today. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 7, 2005, at 3:26 AM, Sylvain Wallez wrote: Jorg Heymans wrote: Sylvain Wallez wrote: The initial foo.bar:input proposal *structurally* prevents name all crispy clear now. It was clear then. As always there are trade offs. In this case Its between possible naming conflicts and a CSS incompatibility (bad practices aside) in 90% of users browsers. Which error will be easier to detect? Which is most likely to affect users? Phew! Sometimes, when there's a lot of background, producing a clear explanation is not an easy task ;-) Now I'm glad I finally was able to do it, and will make sure this is written in the docs, to avoid the same effort later in the future :-) as opposed to sooner in the future? ;-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [VOTE] Naming rule for HTML IDs generated by CForms
On Nov 6, 2005, at 4:13 PM, Sylvain Wallez wrote: Jean-Baptiste Quenot wrote: * Sylvain Wallez: The main point being that this rule *must* ensure that generated IDs can never conflict with widget full names (e.g. foo.bar-input would potentially conflict with a bar-input widget sibling of bar). Then why don't you use a « reserved » keyword inbetween, such as « bar-___reserved_cforms_input___ »? Because I'm concerned by the length of these generated IDs that will clutter up the page. I understand this concern but in general I think distinguishing between auto generated names (ids) and author generated names is a good idea. A convention for auto generated names is to begin them with _. In this case it can conflick with auto-generated widget names. A simple convention for naming in this case could be simply to use something along the lines of foo.bar._cfInput or, since this likely will step on some widget names, foo.bar._agInput (ag for auto- generated). A concern here is that root of the ID is somewhat obscured. An alternative naming would be along the lines of foo.bar.cf_input. While not following the more general convention it comes close. (I'm sure someone will confuse it for a column name ;-).) While there remains clutter it is significantly reduced to 3 characters per id. A minimal amount considering the clarity it brings. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
