Fwd: Some ideas for FLUID-1872

[Michelle D'Souza]

Forwarding Simon's message to the list.

Begin forwarded message:
>
> From: Anastasia Cheetham <a.cheetham at utoronto.ca>
> Date: January 15, 2009 4:18:30 PM GMT-05:00
> To: Jacob Farber <jacob.farber.work at gmail.com>
> Cc: Fluid Work <fluid-work at fluidproject.org>
> Subject: Re: Some ideas for FLUID-1872
>
>
> On 15-Jan-09, at 1:43 PM, Jacob Farber wrote:
>
> 1) Could'nt we clean up the samples to become exemplars?
>>
>
> All of our samples should be exemplars :-)
>
> However: The files that you created as springboards contain generic  
> data ("item 1," "item 2," etc.), very suitable for cut and paste.  
> The files the the sample-code folder have more 'sample' data (for  
> example, the conference planning list).
>
> Do we want to have both kinds of samples, and just call them all  
> "functional demos?"
>
>
> 2) As for the semantics for "real-world" perhaps it could be  
> something like "implementations" or "partner-demos" or "use-cases".
>>
>> I would think a full instance of, say, Sakai wouldnt matter since  
>> its a demo of client-side functionality with the assumption the  
>> project implementor has intimite knownledge of their own system  
>> (ie. a uPortal person doesnt need to see how we set up uPortal  
>> proper, just whats expected of them on the front-end and they could  
>> make the necessary changes in their uPortal instance.). Please  
>> correct me if Im wrong, but as long as the markup is what the app  
>> spits out normally, then they shouldnt have a problem. The whole  
>> system doesnt need to be up and running to showcase a small peice  
>> of functionality.
>>
>
> I agree that we don't want or need a full sakai instance. I'm  
> concerned that someone seeing the phrase "real-world-demos" *might*  
> expect it to be a sakai instance, and I'm only wondering if we might  
> want a different name. But I could just be being pedantic :-)
>
>
> -- 
> Anastasia Cheetham                   a.cheetham at utoronto.ca
> Software Designer, Fluid Project    http://fluidproject.org
> Adaptive Technology Resource Centre / University of Toronto
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>
> ------------------------------------------------------
> Michelle D'Souza
> Software Developer, Fluid Project
> Adaptive Technology Resource Centre
> University of Toronto
>
>
>
>
>
> From: "Wang, Simon" <slwang at exchange.ubc.ca>
> Date: January 19, 2009 6:34:59 PM GMT-05:00
> To: "Jacob Farber" <jacob.farber.work at gmail.com>
> Cc: "Fluid Work" <fluid-work at fluidproject.org>
> Subject: Some ideas for FLUID-1872
>
>
> Hi Jacob,
>
> When I tried to change the build.xml to make it is able to build by  
> components (Fluid-224) I noticed that in the current directory  
> structure, we have to “hard code” the components and the dependent  
> files into the configuration file. To make it easy for automation,  
> the directories should be structured by functions.
>
> I mentioned in Fluid-224, the recommended directories under fluid- 
> components/ directory as following:
> 1.        The basic Fluid files reside under the respective js/ 
> fluid, css, html, and images directories.
> 2.        Each Fluid component has its own directories, under the  
> respective js/fluid, css, html, and images directories, and all the  
> files associated with one component reside in these directories.
> 3.        Any JavaScript not depended on by all Fluid components is  
> in a separate file.
> 4.        A Fluid component has all its component dependent files in  
> its own directories. In case of one file is shared by two component,  
> then each of the two components need to have this file in their own  
> directory.
> 5.        CSS files are organized in basic and component way.
>
> Having a real-world-demos directory is a good idea. It should  
> contain documents about how to integrate fluid in applications,  
> install and run examples (sakai, uPortal, and etc.), and links to  
> integration partners. The examples should be very easy to install  
> and run and easy for the users to see how powerful fluid is and how  
> easy to integrate, see the differences when they change something in  
> fluid set ups. Otherwise, a link to the remote site is enough,  
> because from there the users can see how these sites are fluidized.
>
> Regards,
>
> Simon
> ________________________________________
> Simon Wang
> Sr. Programmer Analyst
> Information Technology - University of British Columbia
> 6356 Agricultural Road, Vancouver, BC, V6T 1Z2, Canada
> Phone: 604-822-0387
> Email: simon.wang at ubc.ca
>
>
>

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090120/d2c0bbe5/attachment.html>