In the other thread, Stan Shepherd, proposed the following proposal:<br><br>what do you think ??? for me is ok.<br><br>Don&#39;t worry for the technology. It can be decided after, by the mentors and student. <br><br>Now...we need a mentor...volunteer???<br>
<br><br><br>........Stan mail:<br><br><br><br>
Hi, I had a first pass at a proposal. Feel free to improve upon it. The<br>
major question is whether we should bite the bullet and nominate what<br>
technologies we would use to build the reference implementation. It would<br>
also make it easier to nominate the mentors, if they are to be experts in<br>
the particular technologies. I think we had some volunteers previously for<br>
Seaside/Grease related projects?<br>
<br>
<br>
Smalltalk is enjoying a resurgence in its development, with a great deal of<br>
development going into building out its abilities to underpin a web<br>
framework.<br>
Auctomatic was a recent startup built in Smalltalk, that received seed<br>
funding from Y-Combinator and was acquired by Live Current Media. People who<br>
build in Smalltalk know that it lends itself to fast development, and that<br>
web aplications can be upgraded on the fly, without the need to take down<br>
the server.<br>
<br>
The goal of this project is to spread the use of Smalltalk to a wider<br>
audience. The scope is to produce a reference implementation of a Smalltalk<br>
stack, in the form of a working e-commerce site. The participants will<br>
select and integrate the preferred technologies, and build on existing<br>
demonstration systems. The result will make it much easier for potential new<br>
Smalltalkers to evaluate the technology, by seeing a fully working example,<br>
and then to get started on their own application by downloading that same<br>
example as a working template.<br>
<br>
The Smalltalk community, and in particular the open source Smalltalk<br>
community, will benefit as follows:<br>
improved quality and documentation of the technology stack at its interfaces<br>
Availability of a one stop solution as the basis for new projects<br>
better ability to attract new participants and projects to Smalltalk.<br>
<br>
The student participant will gain experience of implementation of a real<br>
world Smalltalk project, and of the practicalities of e-commerce<br>
development. The student would be well positioned to participate in a<br>
startup using the technology stack.<br><br><br><br><div class="gmail_quote">2010/3/11   <span dir="ltr">&lt;<a href="mailto:tallman@inbox.ru" target="_blank">tallman@inbox.ru</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

&gt; &quot;...to show the rest of the world what kind of things can be done in Smalltalk nowadays&quot;<br>
<br>
Yes. I really hate strange situation, when people &quot;likes&quot; smalltalk. Sometimes they even make some cryptic tools for smalltalk. But, when some end-user application needed, they don&#39;t choose smalltalk for it. Even if they have a choice. Don&#39;t know about ESUG, but in RSUG (Russian Smalltalk Users Group) it&#39;s a common situation.<br>


<br>
Generally, I hate the situation, when it&#39;s &quot;cool&quot; to make system tools, tools for developing, tools for tools for developing, fremeworks, sometimes really very cool and usefull...but somewhy it&#39;s &quot;not cool&quot; to use all this staff to make real applications to solve real problems. What all this cool stuff for then, huh?<br>


<br>
&gt; The idea is to present potential newcomers to Smalltalk with a viable stack that could be picked up as is, to give a<br>
&gt; starting point for developing web applications.<br>
<br>
I working for SmallPOS (<a href="http://squeaksource.com/SmallPOS.html" target="_blank">http://squeaksource.com/SmallPOS.html</a>) project for some time. And it&#39;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.<br>


<br>
&gt; edit<br>
&gt; copy<br>
&gt; search<br>
&gt; display in list<br>
&gt; display in report<br>
&gt; a stuff or a list of stuff.<br>
<br>
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:<br>
- generating of lists and tree-like lists from magritte descriptions<br>
- list filters and list fast searches based on magritte descriports, too<br>
- custom magritte descriptors, components and memento, custom magritte renderers and, generally, how to use Magritte descriptions for something new, not-yet-implemented<br>
- using both full-generated, full-customized and _partially-customized_ (you don&#39;t touch component&#39;s structure, and you uses magrittes field editors, but you can fully control when they situated) web-forms<br>
- using web-forms with table parts inside them<br>
- 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)<br>
- using GLORP with sometimes not-trivial mappings (not VERY untrivial I&#39;m sorry)<br>
- using (custom magritte) mementos to fight the absence of nested UnitOfWorks in GLORP, so nested editing becomes possible<br>
- 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.<br>
- using KomHttpServer to host files like icons and CSS-styles.<br>
<br>
I beleive this list will be expanded &#39;till GSoC will begins. So, maybe it will help to solve problem<br>
<br>
&gt; The only thing I am concerned a bit is the scope of the project. It seems quite big.<br>
<br>
Maybe using SmallPOS as a basis will make things easier and faster, and avoid some already-made efforts. Well, SmallPOS is not &quot;web shop&quot;, it&#39;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.<br>


<br>
Another problem necessary to solve is: I try to keep code more or less clean, but due to time restrictins I can&#39;t totally avoid fast dirty tricks. I just trying to mark them for future fixes :)<br>
<br>
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&#39;s not a conceptual problem, but it makes fast education virtually impossible for non-russians.<br>


<br>
Finaly, PayPal prohibits receiving money for russian users, so I can&#39;t make a paypal connector for e-business...I just can&#39;t test it ;)<br>
<br>
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 ;)<br>
<br>
<br>
_______________________________________________<br>
Esug-list mailing list<br>
<a href="mailto:Esug-list@lists.esug.org" target="_blank">Esug-list@lists.esug.org</a><br>
<a href="http://lists.esug.org/listinfo/esug-list" target="_blank">http://lists.esug.org/listinfo/esug-list</a><br>
</blockquote></div><br>