Re: Release Work

Hi Marc,

First, I like Spring for all of its architecture neutral advances. I am 
going to start using it regularly. I just do not like XML as a 
configuration language but since I use ant all the time, I can live with 
it. I know, for example, I could write a basic container using the #bean 
and #properties directives as IOC enablers in a few hours as a proof of 
concept.

I do not want WM to be Spring-dependent. So, let's be sure about that. 
Spring-friendly, absolultely. And, I will work with you on this.

I do not see the big character-flaw in the Broker or in the way WebMacro 
pulls its basic properties. Invoking an instance of WebMacro from a 
Spring Container should be very straight-forward as is and, if needs be, 
there could be Decorator to assist in the initialization of WebMacro. 
But, I will always keep an open mind.

Lane

Marc Palmer wrote:

>>Whatever, WebMacro configuration needs to be "bean scriptable". I am
>>not
>>suggesting any replacement of the existing properties config scheme for
>>WM
>>- but it -must- be possible for users to configurable WebMacro at
>>runtime,
>>and from any POJO configuration tool such as Spring, Pico etc.
>>    
>>
>
>Let me qualify this a bit more - in my "dream" of WM 3 we'd have POJOs
>that let us configure a WebMacro instance - both initially at startup
>using somethign like Spring, but also at runtime for non-persistent
>changes to the config such as temporarily adding a new directive. A Spring
>bean config XML might look like this:
>
>
><beans>
>   <bean id="myBusinessLogic" class="com.somecorp.LogicClass">
>      <property name="datastore" ref="myJDBCstorage"/>
>   </bean>
>
>   <bean id="myJDBCstorage" class="com.somecorp.JDBCStorageClass">
>      <property name="datasource" value="java:comp/env/jdbc/TestDB"/>
>   </bean>
>
>   <bean id="someDirective" class="com.somecorp.SomeDirectiveClass">
>      <property name="datastore" ref="myJDBCstorage"/>
>   </bean>
>
>   <bean id="webmacro1" class="org.webmacro.WebMacroConfiguration">
>      <property name="baseConfiguration" value="file:wm.properties"/>
>      <property name="contextTools">
>          <map>
>             <entry key="logic" value-ref="myBusinessLogic">
>          </map>
>      </property>
>      <property name="directives">
>          <map>
>             <entry key="specialdirective" value-ref="someDirective">
>          </map>
>      </property>
>   </bean>
>
>   <bean id="webmacro2" class="org.webmacro.WebMacroConfiguration">
>      <property name="baseConfiguration" value="file:wm2.properties"/>
>      <property name="contextTools">
>          <map>
>             <entry key="logic" value-ref="myBusinessLogic">
>          </map>
>      </property>
>   </bean>
>
>   <bean id="uiController1" class="com.somecorp.MyUIController">
>       <property name="webmacro" ref="webmacro1"/>
>   </bean>   
>
>   <bean id="uiController2" class="com.somecorp.MyOtherUIController">
>       <property name="webmacro" ref="webmacro2"/>
>   </bean>   
></beans>
>
>Now for anyone not familiar with Spring, the above will create a bunch of
>Java objects (using the "class=" attribute value) calling their default
>constructors and then will automatically set the properties on those
>objects including resolving references to other beans within the context,
>independent of order in the XML file.
>
>Anyway, the above shows how simple it would then be to configure WebMacro
>for a single application that has:
>
>* Multiple WM instances, initialized from different config
>* WM instances initialized with context tools that are configured with
>references to other configuration-domain objects -without- the use of ugly
>singletons in your application, or arguably worse JNDI (yes I used a JNDI
>datasource just to save space...). Remember, those beans referenced by the
>WM config could be anything, and exist anywhere. Your WM setup /
>application no longer needs to know.
>* Wiring of WM instances to other components such as your controllers/actions.
>
>This is -great-!
>
>It would also be possible to allow configuration of Context "templates" so
>that whenever WM needs a new context it takes it from a bean factory
>configured in the Spring XML - thus externalizing this config from WM and
>most importantly integrating it with Spring applications. 
>
>Like the XML or not Lane, -lots- of people out there are using Spring and
>havnig WM non-configurable from it is very ugly indeed, forcing you or
>end-users to understand and use multiple configuration schemes/tools. 
>
>It makes WM much less attractive. I haven't checked but I'm pretty sure
>that Velocity config is Spring friendly.
>
>$0.02 :)
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Webmacro-user mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/webmacro-user
>
>  
>

-- 
Lane Sharman
Providing Private and SPAM-Free Email
http://www.opendoors.com
858-755-2868