Compound Theory

v2.0

Categories

  1. Transfer
  2. ColdFusion
  3. JRuby
  4. Java
  5. ColdSpring
  6. Squabble
  7. JavaLoader
  8. ColdDoc
  9. 2ddu
  10. AsyncHTTP
  11. OO Analysis and Design
  12. Flex
  13. Railo
  14. XML / XSL
  15. Hibernate
  16. ColdFusion Builder
  17. Fall
  18. Ubuntu
  19. XHTML / CSS
  20. Eclipse
  21. Git
  22. Oracle Database
  23. Usability / UI Design
  24. webDU
  25. cf.Objective()
  26. LWJGL
  27. cf.Objective(ANZ)
  28. Captcha
  29. MAX
  30. Melbourne CFUG
  31. Martial Arts
  32. Random Things
  33. Conduit

Recent Posts

Projects

Recent Comments

19 December 2011 07:41 PM 0 Comments

Custom Schemas in Coldspring 2

One of the most powerful new features in Coldspring 2 is the ability to create custom xml schemas that can be used within your XML configuration.

Rather than go into the details of how to write and configure custom schemas, here is an example of one that comes bundled with CS2 out of the box.

In Coldspring 1.x, if you ever wanted to create a standalone structure inside your XML configuration, you would quite commonly create it through a MapFactoryBean like so:

<bean id="myMap" class="coldspring.beans.factory.config.MapFactoryBean">
<property name="sourceMap">
    <map>
        <entry key="keyA" value="keyA value"/>
        <entry key="keyB" value="keyB value"/>
        <entry key="keyC" value="keyC value"/>
    </map>
</property>
</bean>

This is all well and good, but the issue here is that you specifically need to know the api of the MapFactoryBean.  If you get any part if the configuration of the MapFactoryBean wrong, you tend to get errors that may not be clear, or potentially no error at all, simply a result that is not desirable.

For example, if you misspell the sourceMap property, Coldspring will attempt to set the property, but it doesn't throw an error when it fails.

<bean id="myMap" class="coldspring.beans.factory.config.MapFactoryBean">
<property name="sourcMap">
    <map>
        <entry key="keyA" value="keyA value"/>
        <entry key="keyB" value="keyB value"/>
        <entry key="keyC" value="keyC value"/>
    </map>
</property>
</bean>

Therefore, all you will get back is an empty struct, and quite possibly a headache trying to debug exactly why this is happening in your code.

In ColdSpring 2, there is a nice, convenient util  custom schema, that exists to do things like create arrays, lists and other data structures for you.  It essentially is a simple wrapper around things like the MapFactoryBean, but the custom schema gives you a code completion and hinting when using an XML editor (that support XML Schemas), as well as better error messages when things go wrong.

So, for example, if I wanted to do exactly the same configuration as above, I would add the xml namespace for util in the head of my xml file, like so:

<beans xmlns="http://www.coldspringframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:util="http://www.coldspringframework.org/schema/util"
        xsi:schemaLocation="http://www.coldspringframework.org/schema/beanshttp://coldspringframework.org/schema/coldspring-beans-2.0.xsd
        http://www.coldspringframework.org/schema/utilhttp://coldspringframework.org/schema/coldspring-util-2.0.xsd "
>

Which would enable the <util:> namespace in my XML editor, and I could quickly type out:

<util:map id="myMap">
        <entry key="keyA" value="keyA value"/>
        <entry key="keyB" value="keyB value"/>
        <entry key="keyC" value="keyC value"/>
</util:map>

And we would have the same result as above, but if something went wrong with your syntax, the IDE should show you what it was, and if it didn’t, you would get a nice error from the XML validation letting you know exactly what it was.

Of course, the whole point of this post, is due to the extensible nature of ColdSpring, you can write your own custom XML namespaces, and register them with your XmlBeanFactory, to do things in very concise and easy to use manner inside your IDEs as well.

This is a very simple example of what can be done with Custom xml schemas. You can drastically change the nature of the BeanFactory as well as the contained beans through this mechanism, but this should hopefully give you a little bit of a taste of what can be done with this new functionality.

09 December 2011 08:30 AM 0 Comments

ColdSpring 2 is available on GitHub

This is something I did a while ago, but for whatever reason, totally forgot to announce publicly.

Thanks to the power of distributed version control, there is a copy of the Git repository for ColdSpring 2 on Sourceforge, as well as one on GitHub.

It goes without saying that GitHub really is the best place for Open Source projects to manage and allow for collaboration with other developers, so it makes sense to have a copy of ColdSpring 2 on GitHub as well.

So get your forks ready, and make some pull requests! :)
07 December 2011 11:19 AM 0 Comments

ColdDoc 1.0 Release (and a move to GitHub)

ColdDoc is one of those projects I don’t work without these days. No matter the project, I’ve always got a stack of CFCs in it, and I need a way to document what objects I have, and what methods they have on them. A great example being the ColdSpring 2 project.  I’ve got my local Jenkins install hooked up to generate the ColdDoc documentation on each run, and I usually run it locally often while developing, so I have an up to date reference of what methods are available to me, without having to dig into actual CFC code.

ColdDoc has been ready for 1.0 release for quite a while, but has yet to be formally pushed out into the wild.

With a little push from behind from @vanderwoud, I got my planned migration of ColdDoc to GitHub into gear, and all is now complete.

Now ColdDoc is hosted on GitHub, which is great, because it really is the best place to allow for community contributions, as well as the documentation ported over into the Wiki.

ColdDoc 1.0’s big new ticket item is interface support (although it doesn’t support multiple interface inheritance), as well as lots of little bug fixes.

So if you are ready to get your automated documentation on, grab a copy of ColdDoc, run it against your current code base, and see what comes out!

And if you have any contributions you would like to make to ColdDoc (and I’m sure there are some out in the wild), please issue a pull request against the repository.