Mariano Martinez Peck wrote: > > 2010/3/11 Юрий Мироненко <tall...@inbox.ru> > >> > "...to show the rest of the world what kind of things can be done in >> Smalltalk nowadays" >> >> Yes. I really hate strange situation, when people "likes" smalltalk. >> Sometimes they even make some cryptic tools for smalltalk. But, when some >> end-user application needed, they don't choose smalltalk for it. Even if >> they have a choice. Don't know about ESUG, but in RSUG (Russian Smalltalk >> Users Group) it's a common situation. >> >> Generally, I hate the situation, when it's "cool" to make system tools, >> tools for developing, tools for tools for developing, fremeworks, >> sometimes >> really very cool and usefull...but somewhy it's "not cool" to use all >> this >> staff to make real applications to solve real problems. What all this >> cool >> stuff for then, huh? >> >> > The idea is to present potential newcomers to Smalltalk with a viable >> stack that could be picked up as is, to give a >> > starting point for developing web applications. >> >> I working for SmallPOS (http://squeaksource.com/SmallPOS.html) project >> for >> some time. And it's very close to what you talking about. Even more, it >> tends to be real application, with real shop using it for trading. I made >> it >> opensource for exactly same reason - to show possibilities, to give an >> example can be used to learn, to give a starting point to not start new >> application from scratch and finally - fight this strange situation with >> rarely practical application of smalltalk. >> >> > edit >> > copy >> > search >> > display in list >> > display in report >> > a stuff or a list of stuff. >> >> Yes, all this and lot of details. I trying to use >> Magritte+GLORP+Seaside+Scriptaculous enviroment. It was a good (and >> unexpectedly painfull) practical experience. So, you can find: >> - generating of lists and tree-like lists from magritte descriptions >> - list filters and list fast searches based on magritte descriports, too >> - custom magritte descriptors, components and memento, custom magritte >> renderers and, generally, how to use Magritte descriptions for something >> new, not-yet-implemented >> - using both full-generated, full-customized and _partially-customized_ >> (you don't touch component's structure, and you uses magrittes field >> editors, but you can fully control when they situated) web-forms >> - using web-forms with table parts inside them >> - nested editing (to add Order you need add person, to add person, you >> need >> to add City it lives at, to add a City you need to add a Country and so >> on) >> - using GLORP with sometimes not-trivial mappings (not VERY untrivial I'm >> sorry) >> - using (custom magritte) mementos to fight the absence of nested >> UnitOfWorks in GLORP, so nested editing becomes possible >> - using AJAX to make interactive - and painless - webforms. You just >> added >> list of affected fields in metadescriptor of given field - and they will >> be >> updated via AJAX when form will be generated. >> - using KomHttpServer to host files like icons and CSS-styles. >> >> I beleive this list will be expanded 'till GSoC will begins. So, maybe it >> will help to solve problem >> >> > The only thing I am concerned a bit is the scope of the project. It >> seems >> quite big. >> >> Maybe using SmallPOS as a basis will make things easier and faster, and >> avoid some already-made efforts. Well, SmallPOS is not "web shop", it's >> POS, >> but it should be quite posible - and even not too hard - to convert it >> into >> webshop. I especially tried to keep it as modular as possible. I want to >> try to use another persistence level and another GUI one day. >> >> Another problem necessary to solve is: I try to keep code more or less >> clean, but due to time restrictins I can't totally avoid fast dirty >> tricks. >> I just trying to mark them for future fixes :) >> >> Next, I absolutely do not worried about internationalisation. Taking into >> account SmallPOS practically (maybe even totally) have no hardcoded >> labels >> (they all comes from magritte descriptors or from domain-specific >> webforms) >> it's not a conceptual problem, but it makes fast education virtually >> impossible for non-russians. >> >> Finaly, PayPal prohibits receiving money for russian users, so I can't >> make >> a paypal connector for e-business...I just can't test it ;) >> >> So there are still a lot of work for a student, but, utilising ready >> results it may make things much easier - or, as an option, it make >> possible >> to reach much more shining results with great efforts ;) >> >
Hi Юрий Мироненко ( is that Tallman? - I got your reply third hand via different lists ;) ) I wasn't aware of SmallPOS, and indeed it sounds like it could be a great starting point for such a project. I'll try to load it up soon; are there any screenshots etc available? I'm glad you've used Magritte for it. Could this act as an abstraction layer for the GUI side? I ask because there seems more action in JQueryUI than Scriptaculous in the Seaside world. It would be perfect if the reference application could be GUI agnostic. Similar argument for persistence back-end. re internationalisation, & putting on a marketing hat for a moment, the name sounds a lot like the fatal disease smallpox. If you're willing to consider rebranding, that could be worth considering. It could be the sort of thing people only notice once your application becomes well known, and then rebranding is difficult. Also re internationalisation, it could be a nice to have feature that people could provide translations for a given phrase in their own language, from within the application. Not hard to do I think, but perhaps would need to be moderated. Thanks for the suggestion, and for supporting the idea, ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1588990.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
