itsalleasy

In looking over the SWF stuff a bit I noticed that it required session. Then I noticed that it didn’t create one if it didn’t already exist. My first reaction was that it should…I mean, you need one anyway right. Well I had decided I was ok with the approach (after thinking about problems when session is created when you don’t expect)…then Erwin posts a question to the dev list asking this very question. (you can follow the thread here, here, here, and here…not sure why it broke up so much).

Basically, it broke into a discussion of how to make SWF work without requiring session (not instead-of, but in-addition to). My take on it is that SWF could ‘do the right thing’ and use the session if it is there, otherwise serialize it to the request (via another hidden param in the form). They would have a custom tag that would spit out the right thing (either the info to pull from session, or the serialized data) and have the controller deserialize if it is on the request, otherwise pull from session.

We’ll see how it all goes, but it looks like SWF will soon support flows without session (for visitors, etc).

I still need to actually give it a closer look…maybe over the weekend.

Back in college, I worked on a project called Shadow netWorkspace. I constantly hear myself saying “Oh, we did that in shadow”. It was seriously before its time. It had portal aspects, widgets (actually each ‘portlet’ could be used as a widget…from other code), even os-like aspects. I keep saying I’ll re-write it in java…and I will…or something like it. Someday.

I think I’m going to write a web framework for php. I’ve been needing to some php stuff here and there for the last few years…I really just kind of hack something together until it works. I didn’t really have the time to learn how to do things ‘right’ in php. So I got to looking and saw their oo capabilities and it got me thinking about applying what I know about the java side of things to php. Should be fun.

I haven’t got any replies to my developer list post yet, but someone posted to the spring user list asking if anyone had ported their ATG app to Spring. I replied with the following:

I’ve only been working with ATG for 2 weeks…but I did put together
some code to tie the 2 IoC containers together that may help you
during the migration.
You can easily reference Nucleus components from Spring by using the
JndiObjectFactory since ATG publishes all the Nucleus components to
JNDI:

<bean id=”test” class=”com.foo.Test”>
<property name=”nucleusBean”>
<bean class=”org.springframework.jndi.JndiObjectFactoryBean”>
<property name=”jndiName”><value>dynamo:/some/nucleus/bean/Test</value></property>
</bean>
</property>
</bean>

Where /some/nucleus/bean/Test is the location of the bean in Nucleus.

You can also go the other way (reference spring managed beans from
Nucleus)…but this is a bit more involved and may not help in you
situation.

In the project I’m on they have half the code nucleus aware and the other half they want to be completly ATG ignorant. The non-ATG half is not currently using an IoC…and when components from the ATG side are needed, singletons are being used instead. The Nucleus components basically have a static getInstance method. I don’t like how this feels. I mean I’m used to “gentleman’s programming” and all, but I’d like to see both sides just take advantage of an IoC.

So I whipped up a proof of concept that links the 2 containers together. The Nucleus side can reference beans in a spring container and vice-versa. This way both sides can co-exist and the code can be blissfully ignorant of the separation. Then the benefits of the IoC can be realized (easier to test, mock, maintain, cleaner code, etc).

It wasn’t that difficult really. It wound up being a spring-driven solution. Spring could easily reference nucleus beans by adding a simple FactoryBean to pull them out by path.

<property name="fromNucleus">
<bean class=”com.foo.NucleusFactoryBean”>
<property name=”nucleusName”><value>/blah/test/Test</value></property>
</bean>
</property>

It was a bit trickier to go the other way. I wound up doing a publishing approach where if you wanted a context to be accessible to Nucleus, you would drop a bean in that container that would publish it for you.

<bean id=”nucleusRegisterBean” class=”com.foo.NucleusRegisterBean”>
<property name=”nucleus”><bean class=”atg.nucleus.Nucleus” factory-method=”getGlobalNucleus”/></property>
<property name=”contextPath”><value>/test/foo</value></property>
<property name=”name”><value>Spring</value></property>
</bean>

Given the above, Nucleus components can reference spring-managed beans at the path /test/foo/Spring/beanName where beanName would be the id of the bean in spring to reference.

Works pretty well.