[wiki] Updated: IocContainerInternals/AdvancedStuff/ScriptingAndXmlConfigurationFiles

   Date: 2004-03-17T14:22:25
   Editor: 130.89.169.128 <>
   Wiki: JicarillaWiki
   Page: http://lsd.student.utwente.nl/jicarilla/IocContainerInternals_2fAdvancedStuff_2fScriptingAndXmlConfigurationFiles

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -134,12 +134,17 @@
 
 At second glance, I hope you can see how these approaches are all reasonably equivalent: all of them accomplish exactly the same, namely the correct execution of the pseudocode example at the start of this page. The current direction in which many container efforts are headed is a very clean seperation between the choice of end-user interaction and their "core" IoC implementation.
 
-== Declaration or method calls ==
+== Declaration or method calls? ==
 
-''TODO''
- * security
- * simplicity
- * one hides more than the other
+I just told you all those approaches are very similar. But many people disagree with me there, for a couple of reasons...
+
+When you '''declare''' your component assembly, there's clear constraints on how you can interact with the system. The declaration can be verified and checked programmatically. You can't "break out of the box" that the container creates for you. "Hacking" things together in a way that's different from how the container designers intended is made very difficult. Proponents of this kind of '''declarative assembly''' say its very '''secure'''. They'll also say a declarative solutions is '''clean''', because you have a very strict responsibility split, and people in various roles are not really allowed to mess with each others responsibilities.
+
+People in favor of a '''scripted''' approach will be happy to point out that the use of scripting is more '''flexible''' (you can often "break out of the box" and do totally different things from what the original designer intended) and more '''powerful''' (scripting languages have things like {{{for}}} loops and {{{if}}} statements).
+
+Advantages of doing things in '''pure java''' is that it is very '''portable''', '''light on dependencies''', and also very '''testable'''. In more practical terms, there's heaps of support for unit testing of java applications, java has a strong syntax with lots of syntax verification (ie, pick any IDE), and of course to run a java program you need nothing but the JVM, which we already need anyway. The pure java approach doesn't usually result in a very clear split of responsibilities, nor is it very flexible (you'll ship compiled code in an application, and that is difficult to change), but it is very powerful.
+
+Clearly, the choice of assembly style can impact many aspects of your application, and is a tough one to make. That's why "religious wars" are fought over it :-D
 
 == Autodiscovery and autoassembly ==
 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click