tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: HiveMind feedback/questions
Date Tue, 09 Sep 2003 15:44:49 GMT


Howard M. Lewis Ship wrote:

>>>>-----Original Message-----
>>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>>>Sent: Monday, September 08, 2003 4:20 PM
>>>>To: Tapestry development
>>>>Subject: HiveMind feedback/questions
>>>>
>>>>
>>>>I put the Adder example together with a LoggingInterceptor in three
>>>>modules and its pretty slick. Although the free form schema 
>>>>gets my head 
>>>>spinning ;). I think it'll take a little bit to get adjusted 
>>>>to living 
>>>>without constraints! I like the fact that it can support 
>>>>        
>>>>
>>both IoC and 
>>    
>>
>>>>SoC, nice! And the documentation is great.
>>>>
>>>>I have a few questions:
>>>>1. What is rationale behind the names <service...> and
>>>><extension-point...>? That would probably clarify my 
>>>>confusion with the 
>>>>names. 
>>>>   
>>>>
>>>>        
>>>>
>>>The naming is a bit tricky.  I eventually ended up with 
>>><extension-point> and <extension> because that part of 
>>>      
>>>
>>HiveMind is very 
>>    
>>
>>>close to Eclipse's plugin model; I decided that rather than have 
>>>competing names, I'd use the Eclipse names.
>>>
>>>To some degree, I wish I had gone with an earlier idea that 
>>>      
>>>
>>I discarded 
>>    
>>
>>>(can't remember why) where an extension point could be either a 
>>>configuration extension point, a service extension point, or both.
>>> 
>>>
>>>      
>>>
>>I had the same thought, but then I thought you might have 
>>differentiated 
>>them because of the special service contributions (create-instance, 
>>...). The other way would have definitely been much more 
>>simpler. Also, 
>>I had all along thought that the Hivemind service was 
>>analogous to the 
>>eclipse extension-point because they both provide behavioral 
>>extensions, 
>>while Hivemind extensions as such only provide objects that 
>>have to be 
>>manipulated by a service or something, am I at a loss here?
>>
>>    
>>
>
>The plugin API is very, very close to the extension points; it doesn't really have the
concept of a
>service.
>It does have special hooks that do the right class loader thing when a contribution is
the name of a
>class. Eclipse doesn't have the <rules> thing to convert the contributions directly
into Java
>objects ... most Eclipse plugins are full of code to walk elements and attributes and
do the
>conversions.
>  
>
This is certainly one area where Hivemind overtakes Eclipse. Using 
Hivemind to build Eclipse would have been a lot more simpler! But I am 
sorry, I still can't see difference between services and eclipse 
extension points, is it because extension points cannot take interceptor 
and factory contributions? But conceptually though, from my 
understanding, services and eclipse extension points can both take 
behavioral contributions and Hivemind extension points cannot. Sorry to 
belabor the point, may be I have to do more reading.

>
>  
>
>>> 
>>>
>>>      
>>>
>>>>It got me a little confused initially,
>>>><service-extension-point...> and 
>>>>        
>>>>
>><config-extension-point...> is more 
>>    
>>
>>>>intuitive to me.
>>>>2. How to debug deferred services when dynamic proxies are 
>>>>used?
>>>>   
>>>>
>>>>        
>>>>
>>>Place your breakpoints inside your service implementation class.  
>>>Proxies and interceptors shouldn't need to be debugged.  In 
>>>      
>>>
>>some cases, 
>>    
>>
>>>there's a method in an abstract class you can place breakpoints in.
>>>
>>>      
>>>
>>I was actually trying to trace the call-chain from 
>>RegistryBuilder and 
>>couldn't proceed after I hit the proxy but I guess I can switch the 
>>service to Singleton for this purpose, right? I shall try 
>>this tomorrow.
>>    
>>
>
>Yes, that's a disadvantage of creating the code at runtime; there's no "source code" for
the
>debugger to step through. The advantages, even over something like XDoclet, is much easier
build
>time environment, and always perfectly in-sync, fewer build-time artifacts (such as generated
Java
>files), etc.
>
No argument here!

>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>http://jakarta.apache.org/commons/sandbox/hivemind/
>http://javatapestry.blogspot.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message