Re: [Pharo-project] [Esug-list] Smalltalk app demo for GSoC
In the other thread, Stan Shepherd, proposed the following proposal: what do you think ??? for me is ok. Don't worry for the technology. It can be decided after, by the mentors and student. Now...we need a mentor...volunteer??? ........Stan mail: Hi, I had a first pass at a proposal. Feel free to improve upon it. The major question is whether we should bite the bullet and nominate what technologies we would use to build the reference implementation. It would also make it easier to nominate the mentors, if they are to be experts in the particular technologies. I think we had some volunteers previously for Seaside/Grease related projects? Smalltalk is enjoying a resurgence in its development, with a great deal of development going into building out its abilities to underpin a web framework. Auctomatic was a recent startup built in Smalltalk, that received seed funding from Y-Combinator and was acquired by Live Current Media. People who build in Smalltalk know that it lends itself to fast development, and that web aplications can be upgraded on the fly, without the need to take down the server. The goal of this project is to spread the use of Smalltalk to a wider audience. The scope is to produce a reference implementation of a Smalltalk stack, in the form of a working e-commerce site. The participants will select and integrate the preferred technologies, and build on existing demonstration systems. The result will make it much easier for potential new Smalltalkers to evaluate the technology, by seeing a fully working example, and then to get started on their own application by downloading that same example as a working template. The Smalltalk community, and in particular the open source Smalltalk community, will benefit as follows: improved quality and documentation of the technology stack at its interfaces Availability of a one stop solution as the basis for new projects better ability to attract new participants and projects to Smalltalk. The student participant will gain experience of implementation of a real world Smalltalk project, and of the practicalities of e-commerce development. The student would be well positioned to participate in a startup using the technology stack. 2010/3/11 ЮÑий ÐиÑоненко <tallman@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 ;)
_______________________________________________ Esug-list mailing list Esug-list@lists.esug.org http://lists.esug.org/listinfo/esug-list
Mariano Martinez Peck wrote:
2010/3/11 ЮÑий ÐиÑоненко <tallman@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.
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@gmail.com>wrote:
Mariano Martinez Peck wrote:
2010/3/11 ЮÑий ÐиÑоненко <tallman@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
Mariano Martinez Peck wrote:
So...I keep the proposal as it first version or do I change something ?
I think it can stay as is, as we're not specifying the technology stack ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589512.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Stan. Today **Stephan Eggermont submitted two prejects that you can see in http://gsoc2010.esug.org/ideas.html The prjects are Tutorial application for Suixoand Add functionality to Suixo I think they are quite related. What do you think ? it is worth to add your proposal ? do a merge ? Thanks Mariano On Thu, Mar 11, 2010 at 7:38 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
So...I keep the proposal as it first version or do I change something ?
I think it can stay as is, as we're not specifying the technology stack ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589512.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
Mariano, the proposals are related in wanting to show the stack fully integrated. The healthcare application wouldn't have the second benefit that it could be set up ready to roll for a web business. I think that would be a key deliverable of the process I had in mind. It sounds like SmallPOS would be a closer fit from that point of view. So I'd prefer to keep them separate; an attempt to do both projects as one would probably be too large to get either part done. Cheers, ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Stan I am lost...do you volunteer to be the mentor of this project ? Tallman can be co-mentor if you want. PLease, let me know as soon as possible cheers mariano On Thu, Mar 11, 2010 at 11:49 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano, the proposals are related in wanting to show the stack fully integrated. The healthcare application wouldn't have the second benefit that it could be set up ready to roll for a web business. I think that would be a key deliverable of the process I had in mind. It sounds like SmallPOS would be a closer fit from that point of view. So I'd prefer to keep them separate; an attempt to do both projects as one would probably be too large to get either part done.
Cheers, ...Stan
-- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.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
I am happy to volunteer, to to co-mentor with Tallman. I would however recommend eg Lukas instead of me, for ready access to a lot of the tacit knowledge about the stack. ...Stan On 12 March 2010 08:36, Mariano Martinez Peck [via Smalltalk] <ml-node+1590257-1441068202-4901@n4.nabble.com> wrote:
Stan I am lost...do you volunteer to be the mentor of this project ?
Tallman can be co-mentor if you want.
PLease, let me know as soon as possible
cheers
mariano
On Thu, Mar 11, 2010 at 11:49 PM, Stan Shepherd <[hidden email]> wrote:
Mariano, the proposals are related in wanting to show the stack fully integrated. The healthcare application wouldn't have the second benefit that it could be set up ready to roll for a web business. I think that would be a key deliverable of the process I had in mind. It sounds like SmallPOS would be a closer fit from that point of view. So I'd prefer to keep them separate; an attempt to do both projects as one would probably be too large to get either part done.
Cheers, Â ...Stan
-- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________ View message @ http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590257.html To unsubscribe from Re: [Esug-list] Smalltalk app demo for GSoC, click here.
-- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590728.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I am happy to volunteer, to to co-mentor with Tallman. I would however recommend eg Lukas instead of me, for ready access to a lot of the tacit knowledge about the stack.
I am a bit busy writing my PhD. We can discuss in the list through. Lukas
...Stan
On 12 March 2010 08:36, Mariano Martinez Peck [via Smalltalk] <[hidden email]> wrote:
Stan I am lost...do you volunteer to be the mentor of this project ?
Tallman can be co-mentor if you want.
PLease, let me know as soon as possible
cheers
mariano
On Thu, Mar 11, 2010 at 11:49 PM, Stan Shepherd <[hidden email]> wrote:
Mariano, the proposals are related in wanting to show the stack fully integrated. The healthcare application wouldn't have the second benefit that it could be set up ready to roll for a web business. I think that would be a key deliverable of the process I had in mind. It sounds like SmallPOS would be a closer fit from that point of view. So I'd prefer to keep them separate; an attempt to do both projects as one would probably be too large to get either part done.
Cheers, Â ...Stan
-- View this message in context:
http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1589873.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
________________________________ View message @
http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590257.html To unsubscribe from Re: [Esug-list] Smalltalk app demo for GSoC, click here.
________________________________ View this message in context: Re: [Esug-list] Smalltalk app demo for GSoC 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
-- Lukas Renggli http://www.lukas-renggli.ch
Ok, thanks. Tallman and I it is then. ...Stan -- View this message in context: http://n4.nabble.com/Google-Summer-Of-Code-2010-news-tp1582769p1590904.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
OK...I have just added this project. Cheers Mariano On Thu, Mar 11, 2010 at 3:00 PM, Stan Shepherd <stan.shepherd414@gmail.com>wrote:
Mariano Martinez Peck wrote:
2010/3/11 ЮÑий ÐиÑоненко <tallman@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
Hi What do you think about a "Seaside app generator". Most "classic" web apps needs a bunch of models, a database and automatic forms to enter datas. (Think about Rails+sqlite+ActiveScaffold). I would like to type something like: SeasideApplication new name: 'MyLibrary'; model: 'Library' hasAttributes:#(name location); hasMany: 'Artwork'; model: 'Artwork' hasAttributes: #(title author); models: #(Book CD DVD) are: 'Artwork'; model: 'Artwork' hasMany: 'Copy'; withMagmaDatabase; generateInPackage: 'SeasideLibrary'. And create all the stuff with magritte forms, jquery and selected database, load the required packages and create basic unit tests. Cheers, Laurent Laffont 2010/3/12 Mariano Martinez Peck <marianopeck@gmail.com>
OK...I have just added this project.
Cheers
Mariano
On Thu, Mar 11, 2010 at 3:00 PM, Stan Shepherd <stan.shepherd414@gmail.com
wrote:
Mariano Martinez Peck wrote:
2010/3/11 ЮÑий ÐиÑоненко <tallman@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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
laurent laffont -
Lukas Renggli -
Mariano Martinez Peck -
Stan Shepherd