On Tue, Oct 18, 2011 at 12:40 PM, thron7 <[email protected]>wrote:
> Franck,
>
> thanks for the feedback :). Here are a few specific remarks.
>
> > * hard to make contrib in the contrib demo browser way (ie, documented,
> > clean, full time job to make a good contrib, but quality have a price
> (time)
> > !)
>
> That's a bit surprising. If you have re-usable components in your work,
> just put them in their own library. Then, from a 'contrib' skeleton
> ('create-application.py -t contribution') copy over the "demo" folder,
> adapt the demo config.json and the code to showcase your library, and
> you're good to go. The setup shouldn't take you more than half an hour.
> The real effort is in writing the demo code. But this is all optional,
> in the first step you can provide a contribution without any demos.
>
Hehe. I've take the time to say that i'm not a professional developer,
and, with this remark below, it just tell me something: i don't code
my components to be re-usable enought. Remove this remark please.
But replace it with "too few contrib". Because simply not enought
contributor --> marketing/evangelisation fault. Just a question of time ?
>
> > * too few "little examples", provided by the community (all tests made in
> > the sandbow should be browseable for inspiration)
>
> What exactly do you mean with "little examples"? Code snippets that
> cannot run on their own? The demos in Demobrowser are often only a few
> couple of lines long, and they are complete programs. Even shorter code
> is often conveyed as Playground samples (although, yes, the standard
> samples are only few). Which granularity of code are you looking for?
> Has it to be immediately runnable? Where do you look for it
> (Demobrowser, manual, Apiviewer, ...)?
>
> What do you mean with "all tests made in the sandbox"?
>
I'm speaking about playground and demo.
Take a demo, by example, split each step in the code of the demo, and
put each time viewable in the playground. That's it.
So i can learn step by step. I really speak about a beginner point of view.
You said "complete programs". When you just read qooxdoo code
for the first time, a "complete program" is to heavy to understand each
step.
And, you know what it is, you never find the perfect demo you need, but
it's often an inspiration. So steps must be separated and easy to read,
just few lines < 50.
Note that demos actualy in place are REALLY usefull and well done.
My remark is just to be a little be deeper.
Regarding "all tests made in the sandbox", it's a new idea.
But i'm not sure it's really new, i think i already seen that somewhere.
Look at http://jsfiddle.net/ you can see "example" in the menu.
When i say "all tests made in the sandbox" i would say "keep an history of
all code
typed in the playground. It's sometimes cool for a beginner to see what
other
beginner (or not beginner) have save. So when you launch a search for
"qx.y.z", you can browse many piece of code. More code to search into, more
easy it is to find something you are trying to do.
My 2 cents !!!!!
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
