- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement

by Igor Stasenko

On 5 January 2011 16:25, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi there, > > While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). > > But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. > > I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. > Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? hmm.. the existence if separate class for each of xml elements doesn't automatically means that it can validate a SOAP document that it is well formed, isn't? > Or would you avoid to subclass ? > > Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) > As to me, i'd better leave the xml domain as soon as possible by validating it and then parsing its elements into something, which is reification of actual SOAP query/response model , without trying to resemble an xml dom tree. > Thanks in advance, > > CÃ©drick > > [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ > > -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages

by CÃ©drick BÃ©ler

it depends what you call dynamic pages :) Personally, I'm in the way to develop a seaside app that will manage "customers" and whose main goal is to generate pure static html pages (which can be changed from the user interface - change mean modified where it's possible and interesting then generated again). Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. You could also have a look at Iliad or Aida which I think are less memory hungry than seaside (but to me, nothing beats pure html anyway with a fake dynamic impression ;) ). My 0.02c, > > > Begin forwarded message: > >> From: Annick Fron <info(a)afceurope.com> >> Date: January 5, 2011 12:43:53 PM GMT+01:00 >> To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> >> Subject: [Pharo-users] Smalltalk server pages >> Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> >> >> Hi, >> >> and in order to get a minimum of dynamic pages, (I think Seaside will be too large for my memory) what is best to get simple Smalltalk server pages, swazoo or Komhttpserver ? >> >> Annick Fron > >

Jan. 5, 2011

[Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement

by CÃ©drick BÃ©ler

Hi there, While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? Or would you avoid to subclass ? Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) Thanks in advance, CÃ©drick [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/

Jan. 5, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #11 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 The problem is that it clearly does nothing at all to improve readability and usability, as long as there is no consistent and complete interface. Without a complete interface redesign, this simply is no improvement.

Jan. 5, 2011

Re: [Pharo-project] IRC meeting next Tuesday, January 4, at ...?

by Alexandre Bergel

+1 Alexandre On 4 Jan 2011, at 19:10, laurent laffont wrote: > On Tue, Jan 4, 2011 at 10:04 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > argh I totally missed my alarm clock on my machine (while cleaning the house :) > So did people discuss? > May be we should redo a clear call. > > +1 > > > Laurent. > > > > Stef > > On Jan 3, 2011, at 9:46 PM, Adrian Lienhard wrote: > > > I just figured that I also can't make it tomorrow at 20:00 (I can be online 2 hours later, though). > > > > Anyway, I suggest that everybody who is interested to discuss and sync meets at 20:00 and it would be nice if somebody could write a short summary, which we can post to the mailing list and the website. > > > > BTW, the channel is #pharo-project on irc.freenode.net. If you don't have an IRC client you can browse to > > > > http://webchat.freenode.net/?channels=pharo-project > > > > Time: http://www.timeanddate.com/counters/customcounter.html?day=4&month=1&year=2… > > > > Cheers, > > Adrian > > > > > > > > On Jan 3, 2011, at 09:15 , StÃ©phane Ducasse wrote: > > > >> Thanks for the call adrian. I will be travelling until 16h (it was not planned when I proposed that dat) but there is no problem, > >> Stef > >> On Jan 2, 2011, at 10:34 PM, Adrian Lienhard wrote: > >> > >>> Hi all, > >>> > >>> During the last meeting [1] we decided to do the next one on January 4 but we didn't decide when to start. > >>> > >>> The previous meeting started at 20:00 CET/UTC/GMT+1, which may not be optimal for people in other time zones. If somebody likes to suggest another time, please let us know soon! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> [1] http://pharo-project.org/news?article=irc-meeting-notes > >> > >> > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 5, 2011

Re: [Pharo-project] [Pharo-users] Minimal pharo

by Adrian Lienhard

Hi Esteban, Yes, I know... So, how do you do the shrinking? ;) Do you unload by package? If yes, are the remaining MC packages "clean" and there are no obsolete classes etc. in the resulting image? Cheers, Adrian On Jan 5, 2011, at 13:21 , Esteban Lorenzano wrote: > Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible. > > Cheers, > Esteban > > El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribiÃ³: > >> >> On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: >> >>> ps: I wonder if any of those scripts should be added to ScriptLoader >> >> Yes, that would be good! Like this we can improve them and other people can contribute. >> >> Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization. >> >> Cheers, >> Adrian >

Jan. 5, 2011

Re: [Pharo-project] Pharo and CommandShell on OSX ?

by David T. Lewis

On Wed, Jan 05, 2011 at 09:00:41AM +0100, Igor Stasenko wrote: > On 5 January 2011 04:12, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Tue, Jan 04, 2011 at 08:03:42PM -0300, Esteban Lorenzano wrote: > >> ah... I think (if I understood well) the real problem is that OSProcess > >> were implementing it's own aio things and now it is relying (correctly) > >> in AioPlugin... so, before that, it wasn't important if AioPlugin was > >> present, and now it is (btw... UnixOSProcessPlugin don't really need > >> AioPlugin, it switches to an ugly but necessary polling when absent) > >> > >> Cheers, > >> Esteban > > > > Yes, that's right. The first version of OSProcess (from 1999) had > > OSProcess and the OSProcessPlugin. Over time, it grew and I split > > it into packages. Now CommandShell and OSProcess are the image side > > packages, and OSProcessPlugin, AioPlugin, and XDisplayControlPlugin > > provide the VM plugin support. All of it is written in Smalltalk, > > including the plugins. > > > > Originally, CommandShell was part of OSProcess. And originally, > > AioPlugin and XDisplayPlugin were part of OSProcessPlugin. > > > > CommandShell uses OSProcess (but loads and runs without it). > > OSProcess uses mainly OSProcessPlugin, but also AioPlugin if > > available. OSProcess also uses XDisplayControlPlugin when running > > on X11, expecially to support #forkSqueak. > > > > The X window system is separate from the operating system, > > therefore the XDisplayControlPlugin is separate from the > > OSProcessPlugin. The aio functions are separate from the > > operating system (they are part of Ian's Unix support code, > > but not OS functions per se), so the AioPlugin is also separate > > from the OSProcessPlugin. > > > What i have learned , that AioPlugin should be included in VM, so > osprocess plugin will use more elegant way of working :) > > > At the higher level, things that relate directly to operating > > system functions and to the representation of OS processes > > are part of OSProcess. Things that relate to the pipes, unix > > shell syntax, file name globbing, command line parsing, and > > shell window display are part of CommandShell. > > > > yes, but it is much nicer to use asynchronous IO for speaking with > those pipes etc, than > synchronous, because VM don't needs to be (b)locked each time. Indeed, that is exactly how it works. AioPlugin provides the mechanism for IO event notification to processes in the image that handle the events, reading available data from a pipe in reponse to the IO event. Input file descriptors are set nonblocking (OSProcessPlugin) for input pipes, and the VM never blocks on input. If AioPlugin is not present, asynchronous IO notification is not available, so polling loops are used instead (but still with nonblocking input). In practice, you will not notice much difference between the polling and the asynchronous input approaches, but I do prefer the asynchronous handlers on aesthetic grounds ;) Dave

Jan. 5, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #10 on issue 3436 by sebastianconcept: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Well.. please ignore who said it, I don't care and you shouldn't be distracted with that, but we are looking at the problem right in the eye: "- It'll break code for no better reason than to increase readability" I don't recall seeing this so clearly. Here is the thing: every time that code usability is considered something "minor" or "wasteful" or "those things that stupid people needs" we are validating that smalltalk: 1. gives a shit about being intuitive 2. gives a shit about newcomers 3. of course shouldn't be mainstream. Every time. Why? Because if Jhon Noob the new developer can't do it (due to an absolutely irrelevant lack of readability) then he will feel excluded and his employer frustrated with the results and his boss tempted to blame the people who convinced him to work that project on smalltalk nobody but old-school people can deal with. It will not matter what we say or understand about it. Facts will talk by themselves in the eyes of other people. And if your plan is to force other people to understand you, then be honest with yourself: you are working to earn the shitty ranking position of your piece of software. So, really? is that what we want? Usability matters (and yes, not only at UI level). Deal with it. If you think that Smalltalk is suposed to be freaking good at that, then make it f* happen. PS: I'm not enjoying to write this cynical thing, but softy feedback is largely proven to be a #fail recipe

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by Hilaire Fernandes

Looks neat. Last time I was told about UIBuilder it was closed, repository wiped out. Does it mean you changed your mind or something else conduct you to develop it? In curiosity. Hilaire Le 05/01/2011 02:18, nullPointer a Ã©crit : > > Finally I implemented the posibility of create a custom windows in > CLFramework. > > The final visual result fails in somethings, but seems the original: > > http://forum.world.st/file/n3174741/example.png > > http://www.youtube.com/watch?v=QAu6fPyz1b0 > http://www.youtube.com/watch?v=Gb9NoWFdhXo > http://www.youtube.com/watch?v=5CpUnIH9KVw -- Education 0.2 -- http://blog.ofset.org/hilaire

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by Hilaire Fernandes

Le 05/01/2011 08:38, Olivier Auverlot a Ã©crit : > uibuilder is a very impressive tool ! > > Pharo must have this type of tool for to be a credible solution in the > development of desktop applications.I think that integrate uibuilder in > the standard image will be a good idea :) Not everyone developer need a UI builder, however it should definitely load through a configuration. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

Jan. 5, 2011