A new critical blog discussing Seaside - now concrete proposals
Locked
1234
1234
Re: A new critical blog discussing Seaside - Comment my blog
 
|
>
> Squeak has quick return methods for this. > > Cheers > Philippe Hi Phillip, :-D I'm sure about that. ;-) I didn't want to direct the discussion into that way! Cucumber mentioned several topics and I just took the accessor things as a sample. These are really questions, I've often been sinking about. How time consuming is it really, if you don't fully follow coding conventions? When I tell a Newbee that he shall put literals into PoolDictionaries, or that he shall avoid isKindOf: and delegate a little more, or that he shall define Dictionaries for switch/case statements, shall take care of public/private, modularize components, then I just see big eyes. There's merely no resource except old 90ies books I can refer to... Every Smalltalk Environment has it's strong advantages. There are a lot of people, already knowing Smalltalk, getting in touch with Squeak just because fo Seaside 2.9. I could image they have the same problems as I had in getting comfortable with Squeak. Once you have worked a while with it, you find a lot of advantages just resideing in the IDE. ECompletion, Refactoring Browser, Community Support.... I don't really share the opinion of the lack of documentation. Sure it is always desireable to have a pdf, or code comments, but and that's a good point from Stephane: There are thousands of Unittests available. They are the best way for documentation. Runnable documentation so to speak. I don't expect the seaside core team to offer a fully documented coding while alpha development! And I know they deliver very much documentation for the final releases. Before I start using a system I have a very close look at the unittests.... There are already very huge projects been build with Seaside, but I have no idea how much of the done work/experience was given back to the Seaside Team. I'm quite sure, that a lot of earlyday users jumped on the train so early, that they now have more a branch of Seaside, better than an easily portable application layer on top of seaside. Maybe some critical comments on Seaside reside exactly on this problem. I will stop posting to that topic, because I already have the impression, that most things beeing said today, are more a "General Philosophy on Smalltalk" than a real "How to improve Seaside". But everybody willing and having the time to give me some hints on, where to find concret topics/resources on "Best Practices" or "Expiriences in building more than sample apps with Seaside"(more the architecural look on things) is very welcome to send me a mail. I will also write my questions on Seaside down and send them to the "poor" Seaside team ;-) Best Regards! Sebastian ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: A new critical blog discussing Seaside - Using getters/setters
|
|
In reply to this post by Richard Peirson
> implemented only if you want to expose that "implementation detail" for > use by other objects. Am I misinterpreting the statement? Not the implementation detail but the accessibility of an instvar. I meant that I want an accessor implemented whenever the accessibility of an instVar should be granted to outside senders. Other way around: Is an instVar internal then it's acceptable NOT to have an accessor. See the example I gave about instVar fields in WARequest: 1) In the current implementation external classes say: aRequest fields at: #someValue -> very bad! It spreads knowledge about over foreign classes. That cannot be seriously considered acceptable Smalltalk style! This requires others to know the implementation details of fields in WARequest. Violates encapsulation badly1 2) I proposed either of these: a) aRequest fieldsAt: #someValue -> well, ok, ca vas b) aRequest get: #someValue -> much better c) aRequest someValue -> best of all where the third one has the advantage that the implementation of the storage of this symbol inside WARequest is even better hidden. We have implemented b) and c) depending on the situation. Please read my post! In my experience it happens only in very rare cases that one (or I here) wants to hide the instVar values from the outside. But one should always hide the implementation details! This is frequently not the case in Seaside. See my post "Proposal 4: Class WARequest". It comprises of 9 concrete proposals and only this one was discussed here. Not to mention the other proposals. And still no comment at all on failing to document! A bad sign proving how little open minded most contributors are on this list. Unfortunately! -------- Original-Nachricht -------- > Datum: Sat, 18 Apr 2009 15:29:00 -0400 > Von: Richard Peirson <[hidden email]> > An: Seaside - general discussion <[hidden email]> > Betreff: Re: [Seaside] A new critical blog discussing Seaside - Using getters/setters > I agree entirely with the points being made by both Michael and Frank on > this topic. > > In fact, based upon this quote taken from Mr. Cucumber's Proposal #1 in > his > Blog, it appears that he does too . . . > > 7) Accessors for other internals > Of course, the same as stated in 6) is true for all other instances held > by > WARequest in its instances. It is never good to let foreigners (classes > outside WARequest) know about implementation details inside another class! > To reming [sic] you: This is what is called encapsulation in the > schooldays > for Smalltalk. > > This sounds, to me at least, to be suggesting that an accessor should be > implemented only if you want to expose that "implementation detail" for > use > by other objects. Am I misinterpreting the statement? > > On Sat, Apr 18, 2009 at 3:05 PM, <[hidden email]> wrote: > > > Once again: > > > > There is no performance difference between accessors and direct > instVars! > > > > Was all tested by us many years ago, because this issue was brought up > as a > > concern. Even dicts for instVars don't really make a difference (very > little > > impact and no practical issue compared to the advantages). All for VW > only. > > > > > > -------- Original-Nachricht -------- > > > Datum: Sat, 18 Apr 2009 20:55:20 +0200 > > > Von: Claus Kick <[hidden email]> > > > An: Seaside - general discussion <[hidden email]> > > > Betreff: Re: [Seaside] A new critical blog discussing Seaside - > > Using getters/setters > > > > > > > > How much difference does the extra method send make in VW, speedwise? > Is > > > this measureable somehow? > > > > -- > > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit > allen: > > http://www.gmx.net/de/go/multimessenger01 > > _______________________________________________ > > seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: A new critical blog discussing Seaside - Using getters/setters
|
|
In reply to this post by Michael Lucas-Smith-3
On Apr 18, 2009, at 10:25 AM, Michael Lucas-Smith wrote: > You don't like "political correctness" which is fine, I don't like > it either.. I do though think there is a thing called politeness, > which is how I personally try to hamstring my communications. > > What I'm seeing a lot of on your blog and on your posts here is your > personal opinion on certain engineering practices that you'retelling > other people to do. Do you realize that people don't like being told > how to think? There are many many "politically incorrect" words one > can apply to somebody who does that. > > Anyway, my minor rant about your approach to communicating with > people aside, on the matter of direct instance variable access, my > personal development style, opinion and likes/dislikes lend toward > using direct instance variable access wherever possible. > > For me, providing an accessor to a variable is like saying "this is > not my personal encapsulated state, it is something you can fiddle > with". That makes an accessor public API to me, so I won't create it > unless I really mean it. > > The behavior of code on my class generally accesses the instance > variables directly for a few reasons: > a) Each object is its own "cell" (biology terms), it is already > encapsulated > b) The object has no need to lie to itself (ie: have the accessor > return something other than the variable itself) > c) Sending 'self' to yourself is a tad psychotic at times. it's a > bit like type declarations in other programming languages.. how many > times do you want me to repeat myself exactly? > > So there you have it. I don't agree with you - now you can vilify me > too. Have at it. I agree with you Michael. I'll throw another one in the mix. I don't like lazy accessors. In particular I do not care for the way the VW UI Builder stuff engages them. Time and time again over the years, I have had to fix difficult bugs because of inconsistencies in initialization graphs. I prefer a "say what you're going to do" approach, like set them in the initialize method if possible. Using lazy accessors for things like ValueHolders just litters extra code all over the place, makes change notification initializations hard to find, etc. My conclusions are based on doing quite a bit of this for quite a while. Just because you *can* do clever things in Smalltalk, doesn't always mean you *should* do them. OTOH, I like to use lazy initializers for things class shares. Inconsistent of me? Maybe. It's a practice that has been honed by, er, uh, practice. As always, there are no absolute answers. Use the right tool for the right job, apply the right (coding) religion at the right time. There, I've taken issue with another one of the points. I'd like to be vilified with Michael. -- Travis Griggs Objologist My Other Machine runs OSX. But then... so does this one. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by TheSmalltalkBlog
[hidden email] wrote:
> Thank you for these statements confirming my proposals: > > >> It is a fact that many squeak codings usually access instance variables >> directly, what makes some coding hard to read and to understand. >> > > Conclusion: > > It would be very simple to use accessor methods in Squeak and it's generally a good idea - not my (C) btw. > > (I am feeling too lazy for find it) he doesnt agree, and neither do I. I have some classes which handle a lot of data and the end up with so many accessors that I cant see the real public api. It is more important that the public interface is clear and easy to understand, than it is to have a load of accessors to private instVars, which aren't part of the public interface, but look like they are in squeak. Another example would be that In some cases the rule which says split this big method into tiny methods can be taken too far. Ten little methods that do the job of one method, make the public interface to the class look 10 times as confusing. Since you have 10 years of experience in Smalltalk as a 10 year old you are dutifully putting in all the accessors because its part of the doctrine. I find myself as 16 year old have been there, but now I find myself taking accessors out and going back to direct instVar access for entirely different reasons. And it was reading Kent Becks advice that started me on this new enlightened path. newThis: newThat: is not a universal convention I certainly don't use it. It is only needed for corecion, #newFromString: There is another convention that states that instanciation should be as readable as possible, and methods in the category "instanciation" should instanciate a fully operational objects, e.g. Point x:y: is perfectly acceptable. Point new setX: 1 y: 3; yourself would also be acceptable, but (Point x: 3) y: 4 wouldnt. i.e #new signifies a potentially incomplete object, whereas #x:y: returns a complete object. > I fully agree! > > So why aren't the Seaside authors willing to learn from such advice? I happen to think that the Seaside coding standards are quite good they may not be perfect, but they are there, they have been thought about and there is some rationale behind them. I have two concerns with your criticisms. Firstly you appear to be criticising seaside 2.8 which is for all practical purposes for this discussion old news. And secondly you are assuming that no one has thought about any of this before, and that no one is wrestling with it now. You are accusing people of ignorance because they don't happen to agree with you, or you dont happen to agree with them. The seaside team has a policy of removing methods that are not actually used by the framework. They have thought about it, and they are willing to defend their stance. I dont agree with them because this means that some useful accessors are not provided just because seaside itself doesnt use them for its own needs (an example of this is that #hasGroupNamed: is not provided in the interface to the application configuration because seaside has no need of it. The fact it is missing renders a useful aspect of configuration needlessly inaccessible to client code. The fact that I disagree with this approach doesnt make them idiots, it means they have intelligently thought about it, and for some reason however odd to me, have come up with a different conclusion. You never know you might learn something, by listening to their rational first before attacking it. /seaside/blah is silly I agree, but there are reasons, it has been discussed before, there are solutions available, and those who have looked at the alternatives have their opinions which they are willing to defend, if you will let them. > Are these poults wiser than the hens? There was no argument brought up to justify this bad practice of direct instVar usage! > > One mans garbage is another mans dinner, its all about perspective. I disagree its not necessarily bad practice. > More on: http://thesmalltalkblog.blogspot.com > Keith _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
[2.8][Opentalk]How to specify location for public files
|
|
In reply to this post by Michael Haupt-3
I'm moving my software from Seaside 2.6 on the VisualWave web server
to Seaside 2.8 on Opentalk. How do I determine which folder public files are served from, and how do I programmatically tell Opentalk which folder to use to serve public files? Thanks, -Carl Gundel http://www.runbasic.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Travis Griggs-4
I am wondering if running on Swazoo makes sense for Run BASIC. Is it
easier to configure than Opentalk? Where can I get a version of Seaside 2.8 for VisualWorks that runs on Swazoo 2.1 or 2.2? I do worry about Swazoo's LGPL license a little. Why LGPL? -Carl Gundel http://www.runbasic.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
2009/4/20 Carl Gundel <[hidden email]> I am wondering if running on Swazoo makes sense for Run BASIC.  Is it easier to configure than Opentalk? To configure what? Make a Swazoo.Site it's easy, and the bind for Seaside it's been made already (you only need one site to serve the whole Seaside framework)   Where can I get a version of Seaside 2.8 for VisualWorks that runs on Swazoo 2.1 or 2.2? I'm about to publish a package for VisualWorks which binds Seaside 2.8 and Swazoo 2.2_beta. It will probably be realised as MIT or similar (my package). Bye Lautaro Fernández
-- Luke LAut SkyFernadezWalker _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Carl Gundel
If you check the archives there is some heated arguments about the
Swazoo licence history. At this point it's LGPL, so can you live with that? On 20-Apr-09, at 8:11 AM, Carl Gundel wrote: > I am wondering if running on Swazoo makes sense for Run BASIC. Is > it easier to configure than Opentalk? Where can I get a version of > Seaside 2.8 for VisualWorks that runs on Swazoo 2.1 or 2.2? > > I do worry about Swazoo's LGPL license a little. Why LGPL? > > -Carl Gundel > http://www.runbasic.com > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote:
> If you check the archives there is some heated arguments about the > Swazoo licence history. > At this point it's LGPL, so can you live with that? I'm not quite sure if I can. I'd really prefer to use Opentalk if I can just figure out how to programmatically: -Get the web server for my Seaside app -Change the port number for the web server -Specify a root folder for static resources so that any URL. For example if I specify the folder to be c:\myseasideapp\public including a file named asdf.html then the URL http://www.mydomain.com/asdf.html resolves to that file. Subfolders should also work. These things are probably easy once you know how to do them, but so far I haven't managed to figure it out. -Carl Gundel http://www.runbasic.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
What is your concern with the LGPL? Do you intend to modify Swazoo?
On Mon, Apr 20, 2009 at 6:55 PM, Carl Gundel <[hidden email]> wrote: > On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >> >> If you check the archives there is some heated arguments about the Swazoo >> licence history. >> At this point it's LGPL, so can you live with that? > > > I'm not quite sure if I can. Â I'd really prefer to use Opentalk if I can > just figure out how to programmatically: > > -Get the web server for my Seaside app > -Change the port number for the web server > -Specify a root folder for static resources so that any URL. Â For example if > I specify the folder to be c:\myseasideapp\public including a file named > asdf.html then the URL http://www.mydomain.com/asdf.html resolves to that > file. Â Subfolders should also work. > > These things are probably easy once you know how to do them, but so far I > haven't managed to figure it out. > > -Carl Gundel > http://www.runbasic.com > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Carl Gundel
See class SeasideServer.
James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: > On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >> If you check the archives there is some heated arguments about the >> Swazoo licence history. >> At this point it's LGPL, so can you live with that? > > > I'm not quite sure if I can. I'd really prefer to use Opentalk if I > can just figure out how to programmatically: > > -Get the web server for my Seaside app > -Change the port number for the web server > -Specify a root folder for static resources so that any URL. For > example if I specify the folder to be c:\myseasideapp\public > including a file named asdf.html then the URL http://www.mydomain.com/asdf.html > resolves to that file. Subfolders should also work. > > These things are probably easy once you know how to do them, but so > far I haven't managed to figure it out. > > -Carl Gundel > http://www.runbasic.com > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Marcin Tustin
>>>>> "Marcin" == Marcin Tustin <[hidden email]> writes:
Marcin> What is your concern with the LGPL? Do you intend to modify Swazoo? I cannot distribute an image that contains LGPL code without it tainting my work (including my subclass of Swazoo to configure the webserver as I need) in a way that is more restrictive than MIT/BSD/Apache, which means there are customers for whom I cannot generate work product. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by James Robertson-7
Ah, I looked at SeasideServer before but I was baffled by the lack of
instance side methods. Everything is in the class methods. Okay, so I look at the rootDirectory method. It returns 'seaside'. Is this a disk folder? I change it to point at my static files using the rootDirectory: method and now my app isn't even found. My Seaside app isn't a disk file, so why does this affect it? Am I supposed to use WAExternalFileLibrary for this? It forces a very long URL. The class comment gives this example http://localhost:7777/seaside/files/external/myfile.png With the VisualWave server I can do this http://localhost:7777/myfile.png Or I can specify a subfolder of the public root: http://localhost:7777/special/myfile.png I realize that I can write my own WAFileLibrary subclass, but it seems like it should be easy to do what I need out of the box. Thanks, -Carl On Apr 20, 2009, at 2:18 PM, James Robertson wrote: > See class SeasideServer. > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: > >> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>> If you check the archives there is some heated arguments about the >>> Swazoo licence history. >>> At this point it's LGPL, so can you live with that? >> >> >> I'm not quite sure if I can. I'd really prefer to use Opentalk if >> I can just figure out how to programmatically: >> >> -Get the web server for my Seaside app >> -Change the port number for the web server >> -Specify a root folder for static resources so that any URL. For >> example if I specify the folder to be c:\myseasideapp\public >> including a file named asdf.html then the URL http://www.mydomain.com/asdf.html >> resolves to that file. Subfolders should also work. >> >> These things are probably easy once you know how to do them, but so >> far I haven't managed to figure it out. >> >> -Carl Gundel >> http://www.runbasic.com >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Swazoo, VisualWorks, and Seaside 2.8
|
|
I'm sorry, why are long URLs an issue for you?
-Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Carl Gundel Sent: Monday, April 20, 2009 12:13 PM To: Seaside - general discussion Subject: Re: [Seaside] Swazoo, VisualWorks, and Seaside 2.8 Ah, I looked at SeasideServer before but I was baffled by the lack of instance side methods. Everything is in the class methods. Okay, so I look at the rootDirectory method. It returns 'seaside'. Is this a disk folder? I change it to point at my static files using the rootDirectory: method and now my app isn't even found. My Seaside app isn't a disk file, so why does this affect it? Am I supposed to use WAExternalFileLibrary for this? It forces a very long URL. The class comment gives this example http://localhost:7777/seaside/files/external/myfile.png With the VisualWave server I can do this http://localhost:7777/myfile.png Or I can specify a subfolder of the public root: http://localhost:7777/special/myfile.png I realize that I can write my own WAFileLibrary subclass, but it seems like it should be easy to do what I need out of the box. Thanks, -Carl On Apr 20, 2009, at 2:18 PM, James Robertson wrote: > See class SeasideServer. > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: > >> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>> If you check the archives there is some heated arguments about the >>> Swazoo licence history. >>> At this point it's LGPL, so can you live with that? >> >> >> I'm not quite sure if I can. I'd really prefer to use Opentalk if >> I can just figure out how to programmatically: >> >> -Get the web server for my Seaside app >> -Change the port number for the web server >> -Specify a root folder for static resources so that any URL. For >> example if I specify the folder to be c:\myseasideapp\public >> including a file named asdf.html then the URL >> resolves to that file. Subfolders should also work. >> >> These things are probably easy once you know how to do them, but so >> far I haven't managed to figure it out. >> >> -Carl Gundel >> http://www.runbasic.com >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Carl Gundel
> > Am I supposed to use WAExternalFileLibrary for this? It forces a very > long URL. The class comment gives this example > http://localhost:7777/seaside/files/external/myfile.png > This path comes from the WADispatcher mostly. If you look at WADispatcher default, you'll see that under 'seaside' is a WAFileHandler registered as 'files'. The file handler looks at all subclasses of WAFileLibrary and in the case of files that are external to the image, we called it #external. You can register your own file handler at any entry point you want. Seaside 2.9 has another mechanism for doing external files built in to it that I'm not familiar with yet. Cheers, Michael _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Carl Gundel
I'm cc'ng vwnc, since this is more of a VW specific question than it
is a Seaside question; I think it would reduce the noise on this list to go there :) James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Apr 20, 2009, at 3:13 PM, Carl Gundel wrote: > Ah, I looked at SeasideServer before but I was baffled by the lack > of instance side methods. Everything is in the class methods. > Okay, so I look at the rootDirectory method. It returns 'seaside'. > Is this a disk folder? I change it to point at my static files > using the rootDirectory: method and now my app isn't even found. My > Seaside app isn't a disk file, so why does this affect it? > > Am I supposed to use WAExternalFileLibrary for this? It forces a > very long URL. The class comment gives this example http://localhost:7777/seaside/files/external/myfile.png > > With the VisualWave server I can do this http://localhost:7777/myfile.png > > Or I can specify a subfolder of the public root: > > http://localhost:7777/special/myfile.png > > I realize that I can write my own WAFileLibrary subclass, but it > seems like it should be easy to do what I need out of the box. > > Thanks, > > -Carl > > On Apr 20, 2009, at 2:18 PM, James Robertson wrote: > >> See class SeasideServer. >> >> James Robertson >> Cincom Smalltalk Product Evangelist >> http://www.cincomsmalltalk.com/blog/blogView >> Talk Small and Carry a Big Class Library >> >> >> >> >> On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: >> >>> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>>> If you check the archives there is some heated arguments about >>>> the Swazoo licence history. >>>> At this point it's LGPL, so can you live with that? >>> >>> >>> I'm not quite sure if I can. I'd really prefer to use Opentalk if >>> I can just figure out how to programmatically: >>> >>> -Get the web server for my Seaside app >>> -Change the port number for the web server >>> -Specify a root folder for static resources so that any URL. For >>> example if I specify the folder to be c:\myseasideapp\public >>> including a file named asdf.html then the URL http://www.mydomain.com/asdf.html >>> resolves to that file. Subfolders should also work. >>> >>> These things are probably easy once you know how to do them, but >>> so far I haven't managed to figure it out. >>> >>> -Carl Gundel >>> http://www.runbasic.com >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Long URLs are ugly and my Run BASIC customers are already complaining
about the long Seaside related URLs. They want them shorter and simpler, so I'm not about to make them even longer than they already are. -Carl On Apr 20, 2009, at 3:14 PM, Boris Popov wrote: > I'm sorry, why are long URLs an issue for you? > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the message > header. > Unless otherwise indicated, it contains information that is private > and > confidential. If you have received it in error, please notify the > sender > and delete the entire message including any attachments. > > Thank you. > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Carl > Gundel > Sent: Monday, April 20, 2009 12:13 PM > To: Seaside - general discussion > Subject: Re: [Seaside] Swazoo, VisualWorks, and Seaside 2.8 > > Ah, I looked at SeasideServer before but I was baffled by the lack of > instance side methods. Everything is in the class methods. Okay, so > I look at the rootDirectory method. It returns 'seaside'. Is this a > disk folder? I change it to point at my static files using the > rootDirectory: method and now my app isn't even found. My Seaside app > isn't a disk file, so why does this affect it? > > Am I supposed to use WAExternalFileLibrary for this? It forces a very > long URL. The class comment gives this example > http://localhost:7777/seaside/files/external/myfile.png > > With the VisualWave server I can do this > http://localhost:7777/myfile.png > > Or I can specify a subfolder of the public root: > > http://localhost:7777/special/myfile.png > > I realize that I can write my own WAFileLibrary subclass, but it seems > like it should be easy to do what I need out of the box. > > Thanks, > > -Carl > > On Apr 20, 2009, at 2:18 PM, James Robertson wrote: > >> See class SeasideServer. >> >> James Robertson >> Cincom Smalltalk Product Evangelist >> http://www.cincomsmalltalk.com/blog/blogView >> Talk Small and Carry a Big Class Library >> >> >> >> >> On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: >> >>> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>>> If you check the archives there is some heated arguments about the >>>> Swazoo licence history. >>>> At this point it's LGPL, so can you live with that? >>> >>> >>> I'm not quite sure if I can. I'd really prefer to use Opentalk if >>> I can just figure out how to programmatically: >>> >>> -Get the web server for my Seaside app >>> -Change the port number for the web server >>> -Specify a root folder for static resources so that any URL. For >>> example if I specify the folder to be c:\myseasideapp\public >>> including a file named asdf.html then the URL > http://www.mydomain.com/asdf.html >>> resolves to that file. Subfolders should also work. >>> >>> These things are probably easy once you know how to do them, but so >>> far I haven't managed to figure it out. >>> >>> -Carl Gundel >>> http://www.runbasic.com >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
Carl,
You can establish shorter entry points. I covered "static" entry points here: http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=seaside_tutorial11 I know this is covered in other Seaside tutorials; that's where I found the info in the first place :) Additionally, using url rewriting, you can advertise any url you want. James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Apr 20, 2009, at 3:27 PM, Carl Gundel wrote: > Long URLs are ugly and my Run BASIC customers are already > complaining about the long Seaside related URLs. They want them > shorter and simpler, so I'm not about to make them even longer than > they already are. > > -Carl > > On Apr 20, 2009, at 3:14 PM, Boris Popov wrote: > >> I'm sorry, why are long URLs an issue for you? >> >> -Boris >> >> -- >> +1.604.689.0322 >> DeepCove Labs Ltd. >> 4th floor 595 Howe Street >> Vancouver, Canada V6C 2T5 >> http://tinyurl.com/r7uw4 >> >> [hidden email] >> >> CONFIDENTIALITY NOTICE >> >> This email is intended only for the persons named in the message >> header. >> Unless otherwise indicated, it contains information that is private >> and >> confidential. If you have received it in error, please notify the >> sender >> and delete the entire message including any attachments. >> >> Thank you. >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Carl >> Gundel >> Sent: Monday, April 20, 2009 12:13 PM >> To: Seaside - general discussion >> Subject: Re: [Seaside] Swazoo, VisualWorks, and Seaside 2.8 >> >> Ah, I looked at SeasideServer before but I was baffled by the lack of >> instance side methods. Everything is in the class methods. Okay, so >> I look at the rootDirectory method. It returns 'seaside'. Is this a >> disk folder? I change it to point at my static files using the >> rootDirectory: method and now my app isn't even found. My Seaside >> app >> isn't a disk file, so why does this affect it? >> >> Am I supposed to use WAExternalFileLibrary for this? It forces a >> very >> long URL. The class comment gives this example >> http://localhost:7777/seaside/files/external/myfile.png >> >> With the VisualWave server I can do this >> http://localhost:7777/myfile.png >> >> Or I can specify a subfolder of the public root: >> >> http://localhost:7777/special/myfile.png >> >> I realize that I can write my own WAFileLibrary subclass, but it >> seems >> like it should be easy to do what I need out of the box. >> >> Thanks, >> >> -Carl >> >> On Apr 20, 2009, at 2:18 PM, James Robertson wrote: >> >>> See class SeasideServer. >>> >>> James Robertson >>> Cincom Smalltalk Product Evangelist >>> http://www.cincomsmalltalk.com/blog/blogView >>> Talk Small and Carry a Big Class Library >>> >>> >>> >>> >>> On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: >>> >>>> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>>>> If you check the archives there is some heated arguments about the >>>>> Swazoo licence history. >>>>> At this point it's LGPL, so can you live with that? >>>> >>>> >>>> I'm not quite sure if I can. I'd really prefer to use Opentalk if >>>> I can just figure out how to programmatically: >>>> >>>> -Get the web server for my Seaside app >>>> -Change the port number for the web server >>>> -Specify a root folder for static resources so that any URL. For >>>> example if I specify the folder to be c:\myseasideapp\public >>>> including a file named asdf.html then the URL >> http://www.mydomain.com/asdf.html >>>> resolves to that file. Subfolders should also work. >>>> >>>> These things are probably easy once you know how to do them, but so >>>> far I haven't managed to figure it out. >>>> >>>> -Carl Gundel >>>> http://www.runbasic.com >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
Thanks James. When you say URL rewriting, do you mean with Apache, or
is this something that is build in to the Opentalk server? -Carl On Apr 20, 2009, at 3:40 PM, James Robertson wrote: > Carl, > > You can establish shorter entry points. I covered "static" entry > points here: > > http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=seaside_tutorial11 > > I know this is covered in other Seaside tutorials; that's where I > found the info in the first place :) > > Additionally, using url rewriting, you can advertise any url you want. > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Apr 20, 2009, at 3:27 PM, Carl Gundel wrote: > >> Long URLs are ugly and my Run BASIC customers are already >> complaining about the long Seaside related URLs. They want them >> shorter and simpler, so I'm not about to make them even longer than >> they already are. >> >> -Carl >> >> On Apr 20, 2009, at 3:14 PM, Boris Popov wrote: >> >>> I'm sorry, why are long URLs an issue for you? >>> >>> -Boris >>> >>> -- >>> +1.604.689.0322 >>> DeepCove Labs Ltd. >>> 4th floor 595 Howe Street >>> Vancouver, Canada V6C 2T5 >>> http://tinyurl.com/r7uw4 >>> >>> [hidden email] >>> >>> CONFIDENTIALITY NOTICE >>> >>> This email is intended only for the persons named in the message >>> header. >>> Unless otherwise indicated, it contains information that is >>> private and >>> confidential. If you have received it in error, please notify the >>> sender >>> and delete the entire message including any attachments. >>> >>> Thank you. >>> -----Original Message----- >>> From: [hidden email] >>> [mailto:[hidden email]] On Behalf Of >>> Carl >>> Gundel >>> Sent: Monday, April 20, 2009 12:13 PM >>> To: Seaside - general discussion >>> Subject: Re: [Seaside] Swazoo, VisualWorks, and Seaside 2.8 >>> >>> Ah, I looked at SeasideServer before but I was baffled by the lack >>> of >>> instance side methods. Everything is in the class methods. Okay, >>> so >>> I look at the rootDirectory method. It returns 'seaside'. Is >>> this a >>> disk folder? I change it to point at my static files using the >>> rootDirectory: method and now my app isn't even found. My Seaside >>> app >>> isn't a disk file, so why does this affect it? >>> >>> Am I supposed to use WAExternalFileLibrary for this? It forces a >>> very >>> long URL. The class comment gives this example >>> http://localhost:7777/seaside/files/external/myfile.png >>> >>> With the VisualWave server I can do this >>> http://localhost:7777/myfile.png >>> >>> Or I can specify a subfolder of the public root: >>> >>> http://localhost:7777/special/myfile.png >>> >>> I realize that I can write my own WAFileLibrary subclass, but it >>> seems >>> like it should be easy to do what I need out of the box. >>> >>> Thanks, >>> >>> -Carl >>> >>> On Apr 20, 2009, at 2:18 PM, James Robertson wrote: >>> >>>> See class SeasideServer. >>>> >>>> James Robertson >>>> Cincom Smalltalk Product Evangelist >>>> http://www.cincomsmalltalk.com/blog/blogView >>>> Talk Small and Carry a Big Class Library >>>> >>>> >>>> >>>> >>>> On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: >>>> >>>>> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>>>>> If you check the archives there is some heated arguments about >>>>>> the >>>>>> Swazoo licence history. >>>>>> At this point it's LGPL, so can you live with that? >>>>> >>>>> >>>>> I'm not quite sure if I can. I'd really prefer to use Opentalk if >>>>> I can just figure out how to programmatically: >>>>> >>>>> -Get the web server for my Seaside app >>>>> -Change the port number for the web server >>>>> -Specify a root folder for static resources so that any URL. For >>>>> example if I specify the folder to be c:\myseasideapp\public >>>>> including a file named asdf.html then the URL >>> http://www.mydomain.com/asdf.html >>>>> resolves to that file. Subfolders should also work. >>>>> >>>>> These things are probably easy once you know how to do them, but >>>>> so >>>>> far I haven't managed to figure it out. >>>>> >>>>> -Carl Gundel >>>>> http://www.runbasic.com >>>>> _______________________________________________ >>>>> seaside mailing list >>>>> [hidden email] >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>>> >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Swazoo, VisualWorks, and Seaside 2.8
|
|
Apache is what I meant
James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Apr 20, 2009, at 3:44 PM, Carl Gundel wrote: > Thanks James. When you say URL rewriting, do you mean with Apache, > or is this something that is build in to the Opentalk server? > > -Carl > > On Apr 20, 2009, at 3:40 PM, James Robertson wrote: > >> Carl, >> >> You can establish shorter entry points. I covered "static" entry >> points here: >> >> http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=seaside_tutorial11 >> >> I know this is covered in other Seaside tutorials; that's where I >> found the info in the first place :) >> >> Additionally, using url rewriting, you can advertise any url you >> want. >> >> James Robertson >> Cincom Smalltalk Product Evangelist >> http://www.cincomsmalltalk.com/blog/blogView >> Talk Small and Carry a Big Class Library >> >> >> >> >> On Apr 20, 2009, at 3:27 PM, Carl Gundel wrote: >> >>> Long URLs are ugly and my Run BASIC customers are already >>> complaining about the long Seaside related URLs. They want them >>> shorter and simpler, so I'm not about to make them even longer >>> than they already are. >>> >>> -Carl >>> >>> On Apr 20, 2009, at 3:14 PM, Boris Popov wrote: >>> >>>> I'm sorry, why are long URLs an issue for you? >>>> >>>> -Boris >>>> >>>> -- >>>> +1.604.689.0322 >>>> DeepCove Labs Ltd. >>>> 4th floor 595 Howe Street >>>> Vancouver, Canada V6C 2T5 >>>> http://tinyurl.com/r7uw4 >>>> >>>> [hidden email] >>>> >>>> CONFIDENTIALITY NOTICE >>>> >>>> This email is intended only for the persons named in the message >>>> header. >>>> Unless otherwise indicated, it contains information that is >>>> private and >>>> confidential. If you have received it in error, please notify the >>>> sender >>>> and delete the entire message including any attachments. >>>> >>>> Thank you. >>>> -----Original Message----- >>>> From: [hidden email] >>>> [mailto:[hidden email]] On Behalf Of >>>> Carl >>>> Gundel >>>> Sent: Monday, April 20, 2009 12:13 PM >>>> To: Seaside - general discussion >>>> Subject: Re: [Seaside] Swazoo, VisualWorks, and Seaside 2.8 >>>> >>>> Ah, I looked at SeasideServer before but I was baffled by the >>>> lack of >>>> instance side methods. Everything is in the class methods. >>>> Okay, so >>>> I look at the rootDirectory method. It returns 'seaside'. Is >>>> this a >>>> disk folder? I change it to point at my static files using the >>>> rootDirectory: method and now my app isn't even found. My >>>> Seaside app >>>> isn't a disk file, so why does this affect it? >>>> >>>> Am I supposed to use WAExternalFileLibrary for this? It forces a >>>> very >>>> long URL. The class comment gives this example >>>> http://localhost:7777/seaside/files/external/myfile.png >>>> >>>> With the VisualWave server I can do this >>>> http://localhost:7777/myfile.png >>>> >>>> Or I can specify a subfolder of the public root: >>>> >>>> http://localhost:7777/special/myfile.png >>>> >>>> I realize that I can write my own WAFileLibrary subclass, but it >>>> seems >>>> like it should be easy to do what I need out of the box. >>>> >>>> Thanks, >>>> >>>> -Carl >>>> >>>> On Apr 20, 2009, at 2:18 PM, James Robertson wrote: >>>> >>>>> See class SeasideServer. >>>>> >>>>> James Robertson >>>>> Cincom Smalltalk Product Evangelist >>>>> http://www.cincomsmalltalk.com/blog/blogView >>>>> Talk Small and Carry a Big Class Library >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 20, 2009, at 1:55 PM, Carl Gundel wrote: >>>>> >>>>>> On Apr 20, 2009, at 1:12 PM, John M McIntosh wrote: >>>>>>> If you check the archives there is some heated arguments about >>>>>>> the >>>>>>> Swazoo licence history. >>>>>>> At this point it's LGPL, so can you live with that? >>>>>> >>>>>> >>>>>> I'm not quite sure if I can. I'd really prefer to use Opentalk >>>>>> if >>>>>> I can just figure out how to programmatically: >>>>>> >>>>>> -Get the web server for my Seaside app >>>>>> -Change the port number for the web server >>>>>> -Specify a root folder for static resources so that any URL. For >>>>>> example if I specify the folder to be c:\myseasideapp\public >>>>>> including a file named asdf.html then the URL >>>> http://www.mydomain.com/asdf.html >>>>>> resolves to that file. Subfolders should also work. >>>>>> >>>>>> These things are probably easy once you know how to do them, >>>>>> but so >>>>>> far I haven't managed to figure it out. >>>>>> >>>>>> -Carl Gundel >>>>>> http://www.runbasic.com >>>>>> _______________________________________________ >>>>>> seaside mailing list >>>>>> [hidden email] >>>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ >>>>>> seaside >>>>>> >>>>> >>>>> _______________________________________________ >>>>> seaside mailing list >>>>> [hidden email] >>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> _______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |