RE: Need strategies, not tactics

I agree, Tim.  I think maybe *that's* what's kept me hanging around.  They're so damned nice when you beat up on them.  :-P
 
In my own defense, I do have to say that I really am trying to help by bringing up all these issues.  Tuff love, I guess.  I've certainly been less helpful with other OSS projects that I've simply abandoned, rather than digging, poking, and prodding in this way.
 
For the record, http://66.105.113.115/vqwiki-2.3.5/jsp/Wiki?ModelHowTo is where I got the idea that a Model is not quite the same as the M in MVC.  It seems more like a facade for the M in MVC than the actual M.
 
Mike, I'll give your reply and the ArchitectureOverview page a thorough reading tomorrow.  Thank you for your quick and generous response.  I guess you could consider Keel (or at least it's authors) a service-oriented architecture.
 
G'night,
Lee
 

	-----Original Message----- 
	From: [email protected] on behalf of [email protected] 
	Sent: Mon 3/15/2004 10:12 PM 
	To: [email protected] 
	Cc: 
	Subject: Re: [Keel User] Need strategies, not tactics
	
	

	Mike, 
	
	I must  say, beautifully addressed.   
	
	Too many projects get upset when people point out deficiencies (docs or otherwise). 
	
	I know it can be frustrating (for all parties, experts & noobs alike), we're trying to learn about your framework, and asking for changes, without yet committing to help out in any way.   
	
	Your friendliness and insight are appreciated. 
	
	Thanks, 
	
	Tim 
	
	
	

	Please respond to [email protected] 

	Sent by:        [email protected] 

	To:        [email protected] 
	cc:        [email protected] 
	
	Subject:        Re: [Keel User] Need strategies, not tactics 
	
	Lee:
	
	Let me see if I can toss in a few cents worth...
	
	> If there is one overall comment I can make about the Keel documentation, it is that there is a shortage, IMHO, of big-picture architectural strategy.  I have been playing around, on and off admittedly, for a few weeks now, and I still am fuzzy on how to architect an application using Keel.  I've picked up on the localized techniques, but what about the global principles?  All the docs, including the HandsOnTutorial are long on tactics and short on strategy.
	
	I think you're right, and I'm going to start a Wiki page with this kind of overview. There are bits of it here & there, though, but not all in one place.
	
	> Knowing how to construct a model is fine, but I still need to know what parts of my application should be implemented as Models, 
	
	The portions of your application that connect the application logic to the UI are the domain of the Model class. It *can* incorporate your application logic completely (although it does not have to). It fits, architecturally, in the same place as a Session Bean in EJB.
	
	> where my models fit into the scheme of things, etc.  I am still confused by the choices of putting my application into the Keel tree or outside of it. 
	
	Put it in the Keel tree to begin with, but within your own module, e.g. app-xxx, just like app-poll.
	
	>  I searched today for information about deploying my app to my web host, but the Wiki is very vague on this subject. 
	
	There are a lot of choices. The simplest is a WAR. The most complex is a grid-based cluster of Keel app servers, with failover and so forth. There's a reference to an article on this on the MakingWaves page.
	
	> Will I end up with a WAR?  Will it have all of Keel in it?  
	
	Yes, you'll end up with a WAR (again, by default, if your *-deploy.properties file says so). It will not have all of Keel, just those services you select (by options in the *-deploy.properties file). 
	
	> What about Struts? 
	
	Yes Struts (or Cocoon, Webworks2, etc) will be in the war as well. Again, depending on settings in the properties file.
	
	>  What if I have multiple apps that I want to deploy into a single instance of Tomcat?  
	
	You have three choices: Deploy multiple instances of Keel, Deploy multiple apps in a single instance of Keel, or deploy multiple "client" portions of Keel all talking to one Keel server (or several, actually, if needed/desired).
	
	> Will I have to install all of Keel multiple times, or can I separate Keel from my app?  I have yet to stumble upon the answers to these questions of fundamental design principles.
	
	The answers are there, but I must admit not as clearly organized as I'd like. The articles page referred to above has a number of articles that give good high-level overviews.
	
	> If I want to create a web site with registration and login, do I need to include features from app-register and app-security in my application somehow, or do I need to choose one of them and copy it as the basis for my new application?  All of these things that are second-nature to you folks are utter mysteries to those of us who are just looking at Keel for the first (or tenth) time.
	
	If you want functionality from app-register, you can simple "turn on" app-register in the deploy file - basically the deploy file "drives" the whole build system, incorporating each required app. You can then override the functionality you want to customize, just like extending a class in Java.
	
	> The other problem I am having is that terminology is thrown around without ever being defined or distinguished as to what exactly it means in Keelville.  The term model appears all over the place, yet seems to be something not quite the same as the M in MVC, but there is no clear explanation of what a Model is in Keel. 
	
	Model is essentially the exact "M" in MVC, really. It represents a single unit of application logic. It can be combined as needed with other models as needed in sequences and workflows, and these combine to create applications. 
	
	> The term "role" seems to also be used without explanation, and I think I've stumbled across others.
	
	Some (if not much) of Keel's terminology comes from Avalon, which underlies Keel. You may want to have a read of the excellent doc on the Avalon site.
	
	> For some reason that I can't explain, I have not chucked Keel.  My frustration level and wheel-spinning are nearing redline, and I am very tempted to move on, but something about the promise of Keel has kept me from leaving.  I don't want Keel to be more roadkill on my journey through the open source superhighway (actually, I feel more like *I'm* the roadkill!), but I currently have to be clairvoyant to take advantage of Keel's wonders.  I'm not, and I just don't want to have to work that hard.  I've got enough to do already.
	
	Let me try to take some of the mystery out, and at the same time, benefit slightly from your frustration by greatly improving our documentation for newcomers :-) It's a fair trade, no?
	
	> Please, guys, help.
	
	Just fire away when you have questions, and we'll do what we can to answer!
	
	Thanks for hanging in there.
	
	Mike
	> 
	> P.S. I mean no offense, despite my tone.  I respect what you've done.  I just can't benefit from it without more information.
	
	Speaking for myself, none taken - quite the opposite, we're being complimented that you're hanging in there :-)
	> 
	> 
	> 
	> *************************************************************************************
	> The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
	> *************************************************************************************
	> 
	
	
	-- 
	Michael Nash
	
	JGlobal Ltd 
	Next-Generation Web Application Development and Open Source Support
	http://www.jglobal.com
	
	Bahamas Commerce and Trade
	Offshore eCommerce Hosting and Business Services
	http://www.bahamascommerce.com
	
	_______________________________________________
	User mailing list
	[email protected]
	http://lists.keelframework.org/listinfo.cgi/user-keelframework.org