[Pharo-project] [Esug-list] Smalltalk app demo for GSoC

Mariano Martinez Peck marianopeck at gmail.com
Thu Mar 11 13:05:41 EST 2010


So...I keep the proposal as it first version or do I change something ?

please let me know as soon as possible

On Thu, Mar 11, 2010 at 3:00 PM, Stan Shepherd
<stan.shepherd414 at gmail.com>wrote:

>
>
> Mariano Martinez Peck wrote:
> >
> > 2010/3/11 Юрий Мироненко <tallman at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20100311/c10a4d83/attachment-0001.html>


More information about the Pharo-dev mailing list