Nice work, Georg. T.
On 11/16/2011 11:38 AM, gkoller wrote: > Hi guys, > > There is a question in here also, in Bolded paragraph #6 below - but mostly > I just wanted to share my complete happiness with you all! After trying 3 > hosts, and several alternative JS frameworks, and even several communication > protocols I have found a combination that just worked pretty much the first > time..... > > YEEEAAAAAA QOOXDOO, > > ....so now I'm ready to get 'really serious'! This was a big step, it > confirms many many things.... from here maybe the work will become more > engineering, and less wrestling with critical and tough decisions with only > partial information. > > <b<i>>I am very very happy with our decision to use Qooxdoo - this so > logically laid out framework has made it humanly possible for one guy to > handle back-end, front-end, communications protocols, and now deployment > (super easy with a little magic), all on top of a less than trivial > application.*/ > > Big night for me! After months of front-end work, I'm even reading a Linux > "Administration book", I have a nice piece (about 70%) of one of our > Front-ends working with a back-end. Unlike what I was thinking I just both > pieces up on the same sight under the Ruby Web Framework that is completely > minimalist: Sinatra on "Thin" (- which is EventMachine + Mongrel on Rack) > > JSon is working out great for communications both ways with the Ruby > Back-end. > > And it is all working in Chrome, Firefox, and SeaMonkey but not in IE8 - it > comes up but the communication is broken. (Leave it to the MS folks...). > > The big mystery that was solved is that I somehow managed to develop > Application.js IN THE WRONG SUBDIRECTORY. It generally worked but I could > never run the generate.py successfully so I just ignored it for about 2,000 > lines. This explains why the help I got here didn't seem to work, and why > the documentation only partly worked. I was one level off when I created > the app and I just kept adding to it, testing into the browser, and so it > went for 2,000 plus lines... now there are a pile of "warnings" to look > into but it is all working. > > *The NEW mystery is really weird. Sinatra has a "send_file" method for > sending off "Static" assets to the client. I put up the qooxdoo app in the > exact qooxdoo structure and tried everything I could think of for hours, > nothing worked. Then I read that "putting the assets into a folder named > "public" would 'work best' with static assests (security?). So I left the > gooxdoo folders and assets exactly as there were and added all of them into > this a empty folder named "public" and away it all went! > > OK? But when I removed the original materials and it refused to work. I > went back and tried it without public - would not work. > > So I am running with everything duplicated twice and its all running. > > I'm a bit of a Linux "Noob" when it comes to file privileges but this is > about the only thing I can think of. > > * > > > Now just a word about the App! > > This is a fairly big part of a generalized framework to generate and use > distributed agents. The module that you can go to at: > > http://SwarmShepherd.com > > is about generating the "Data Agents" which (can) become part of a > KnowledgeSystem which is based on a completely Object Based. "Records" are > actually "living breathing" Ruby Objects that have inherited a good deal of > additional functionality. > > Why I think this could be interesting to folks here is that there will be a > completely generalized Qooxdoo Front-end to Add/Delete/Modify information > into this flexible and imho - very powerful system. Hint#1 - data is > entered in Natural Language and optionally there is "Easy to use encoding > services" built in. And this is not too easy to explain but if you look at > the "Build" page at the above site you can see how a system of multi-part > Keywords are used to map to data choices (the 3rd column). Doing no more > than selecting choices encoding is made easy and errors are greatly reduced. > I'm looking forward to adding a lot of cool features to enhance this further > - Drag& Drop might work out to be the way to go? > > What I put up tonight is just 100 medicinal herb objects. The "Topic" > (method) was frozen to "General" for testing reasons and so on. Its a > first test.... feel free to look around? The "Viewer Page" should be live > so you can step thru the stored information herb by herb with Natural > Language above and Encoded information ("Satz" or raw encoded format) below. > > I may not have time to respond for several days > > > Cheers, > > > George Koller > SwarmShepherd.com > > > > > > > -- > View this message in context: > http://qooxdoo.678.n2.nabble.com/Qooxdoo-used-in-a-Generalized-Distributed-Agent-System-one-piece-now-70-up-tp6999958p6999958.html > Sent from the qooxdoo mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > 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. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
