Engage restructing proposal

[Antranig Basman]

Do you mean, you will invite comments soon, or that you invite comments 
that will occur soon? :P
Running the risk of jumping the gun if the former:
i) I assume that engage-client is also nested inside src/webapp as well...
otherwise I guess we would not easily be able to composite it inside
Maven.
ii) I object to the somewhat arbitrary distinction between "components"
and "services" which obscures the generally harmonious bent to the 
framework :P
I guess there will in time be more to what I hope we will not call a 
"service" than a single .js file, since these will have their own 
configuration/manifest supplied in some JSON structure.
iii) whilst "mapping" doesn't actually contain any mapping, it does 
contain a lot of useful JSON to XML benchmarking - I am guessing by 
"remove from SVN altogether" you just mean "do not promote from 
incubator along with the rest of Engage"?
iv) concerned about having engage client-specific framework, I've looked 
over it a bit, but don't see anything particular about most of it that 
insists it lives on the client, although it does touch some tags. But 
this does touch a quite interesting issue that we should ponder, even if 
we don't do anything about it -

Right now - all of the code we have on the server, has visibility of all 
of the code we write on the client - even that large part of it relating 
to DOM manipulation, DOM events, etc. that is useless. Whilst in some 
sense this is not correct, I guess we justify this by noting that the 
costs of loading superfluous code on the server (once per server 
startup) are much lower than loading it on the client (once per page 
serve). All the same, it is not great, and we should give at least some 
thought to the concept of a "core framework" which consists just of 
those definitions which make sense both on the client and the server. In 
terms of infusion, this is not too hard, since it consists largely of 
Fluid.js and the Renderer, plus or minus a few bits and pieces. So, I 
think we should make efforts to ensure that as we "go forward", engage 
code is designed with this in mind too - that is, parts of the code 
which are "model-directed" and interact with markup only through the 
renderer, and parts of code which get involved with grubby details of 
DOM manipulation.


a.cheetham at utoronto.ca wrote:
> 
> I was asked to bring my Engage-newbie eyes to help with the tasks of 
> restructuring the file hierarchy. Many thanks to Yura and Colin for 
> helping me to understand how Engage works, and for answering all of my 
> questions.
> 
> With a bit of brainstorming, Colin and I have come up with the following 
> proposed structure. We invite comments, questions, suggestions. Soon.
> 
>   /infusion
> 
>   /engage-client
>     |- /framework
>     |- /components
>          |- /ArtifactView
>               |- / <subfolders as current for all components>
>          |- /Browse
>          |- /Cabinet
>          |- /NavigationList
>          |- /Description
>          |- /ScreenNavigator
>          |- /Tags
>     |- /infusionTesting
>     |- /integration_demo
>     |- /mobileFSS_demo
> 
>   /engage-server/src/webapp
>     |- /kettle
>          |- /js
>          |- <config files>
>     |- /application
>          |- /js
>               |- EngageApp.js
>          |- <config files>
>     |- /services
>          |- /artifactView
>               |- /js
>                    |- artifactView.js
>          |- /browse
>               |- /js
>                    |- browse.js
>          |- /kettleDemo
>               |- <as existing>
>     |- /WEB-INF
> 
>   ** remove /mapping from SVN altogether
>