FileLibrary / css files confusion

I am using just Squeak + Seaside, no Apache. I have the current Seaside 2.8
from Package Universe.

I want styles in a single place (styles.css file, or a #stylesCss method,
don't care which one). I want changes in that single place to be instantly
reflected in what I see in the browser (just development mode).

What is the simplest possible thing I can do to make this work? Edit
#stylesCss to change the literal text? Edit an external styles.css file?

I find that I make changes to #stylesCss or to the external file styles.css,
and neither one shows up in what the browser sees (checked through FireBug).

Below is exactly what I see at the moment:

Firebug:
li.menuItem {font-size:0.8em;} /* NOTE: this is an OLDER version */

#stylesCss:
^ 'li.menuItem { font-size: small; display: inline;}'

The version sent to the browser is not the current version of either
#stylesCss or styles.css.

This is getting me quite confused and frustrated. Any help, clarification,
etc. appreciated!

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I find that the main reason for my new style edits being ignored by
firefox is that they contain an error.
I think that if your style sheet contains an error firefox continues to
use the old version.

I myself use the WACss class which is part of the Jetsam package. This
allows me to manage bits of css in methods, which is far easier to
navigate. You can also parameterize colors and so forth.

Once you have finished development you can (in theory) use the wrote to
files button to generate a file to be served statically

best regards

Keith
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Keith Hodges" <[hidden email]> wrote in message

>I find that the main reason for my new style edits being ignored by
> firefox is that they contain an error.

I checked, and that is not what is happening here. I even tried:

styleCss
    ^ ''

and

styleCss
    ^ ' body {} '

And the browser (both FFox and IE) still sees an old, complete, css file
(from somewhere!)

- Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Sophie,

Personally, I'd use external static stylesheets (i.e. CSS files) every
time, mainly because I don't like having my CSS spread out all over
the place and because I can then use whatever favourite CSS editor I
want. I also don't like having huge methods with lots of css in one
string - goes against my Smalltalk instincts ;-) That way, if a
project becomes large enough to have a "real" CSS designer (rather
than just me tinkering with it in the early stages), the designer
doesn't have to know Squeak/Smalltalk in order to work on the
stylesheet. For a single web site, I'd start out with a single
stylesheet, then maybe add more as the site evolves, say an extra one
for print media, etc. A single stylesheet would also make it easier to
see whether you're overriding the expected li.menuItem property
somewhere further down in your DOM hierarchy. Single stylesheet =
single error source (i.e. at least it's all in one place when looking
for errors).

But that's just personal preference, use whatever works best for you.

I don't use FF much, so I can't tell you exactly where, but there
should be a setting where you can determine how often you want to
refresh certain files (rather than using cached versions). Set it so
that CSS sources are "always" checked for newer versions on the
server. If you then use a single css file, changes to it should be
reflected as soon as you refresh the page in the browser. (In Opera,
it would be Preferences > Advanced > History > Check Documents:
Always.) If nothing else works, clear your cache completely so you at
least know you're getting the newest version, and perhaps even have
your stylesheet validated (http://jigsaw.w3.org/css-validator/)... to
be sure, to be sure ;-)

Cheers,

Amos


On 1/2/08, itsme213 <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"itsme213" <[hidden email]> wrote in message news:flf7i6

Some progress to report:
I had previously replaced '/seaside/' from my URLs by doing:
 WADispatcher default setName: self 'myBase'.
 WADispatcher default defaultName: ''.

This is apparently what was making my FileLibrary go crazy. When I stopped
messing with this, my #stylesCss starts working fine.

But I _really_ do not want that '/seaside/' in my URLs, even in
non-production (i.e. demo) mode. I have seen the previous (inconclusive)
discussions about doing this.

I'm somewhat stuck right now. Any suggestions?

As a data point, I really think that '/seaside/' in the URL should be
entirely configurable, and totally removed by default.

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I had previously replaced '/seaside/' from my URLs by doing:
> WADispatcher default setName: self 'myBase'.
> WADispatcher default defaultName: ''.

Accessors of the form #setSomething: are private by convention, you
should not call them directly unless you exactly know what you are
doing. The base path cannot be changed using #setName:.

> As a data point, I really think that '/seaside/' in the URL should be
> entirely configurable

I agree that it should be configurable. I filed a bug report:
http://bugs.squeak.org/view.php?id=6833

> and totally removed by default.

I find it more appropriate to have the /seaside prefix by default. I
have many web applications running on my development and deployment
machines and this helps a lot to integrate with other applications.
Changing it does not make anything easier, it just makes 5 years of
Seaside blogs and tutorials obsolete.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > I had previously replaced '/seaside/' from my URLs by doing:
> > WADispatcher default setName: self 'myBase'.
> > WADispatcher default defaultName: ''.
>
> Accessors of the form #setSomething: are private by convention, you
> should not call them directly unless you exactly know what you are
> doing.

Really? Interesting, I hadn't heard about that in other flavours of
Smalltalk. Is it a general Squeak convention or a Seaside convention?

Shouldn't #setName: be in the 'private' protocol then, rather than in
'initialization'? That's how I was taught to do it, way back when,
and/or to add a "private" method comment for unsuspecting browsers.
I've encountered other conventions, like #_name:, #privateName: or
#basicName: rather than simply #name:, for various purposes, but not
the #setSomething: one.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Accessors of the form #setSomething: are private by convention, you
> > should not call them directly unless you exactly know what you are
> > doing.
>
> Really? Interesting, I hadn't heard about that in other flavours of
> Smalltalk. Is it a general Squeak convention or a Seaside convention?

No, this is Kent Beck, Smalltalk Best Practice Patterns: Constructuor
Parameter Method. (page 25)

Also check out the Seaside coding-conventions:
http://www.seaside.st/community/conventions

> Shouldn't #setName: be in the 'private' protocol then, rather than in
> 'initialization'?

The initialization protocol is private, it should never be called from outside.

> That's how I was taught to do it, way back when,
> and/or to add a "private" method comment for unsuspecting browsers.
> I've encountered other conventions, like #_name:, #privateName: or
> #basicName: rather than simply #name:, for various purposes, but not
> the #setSomething: one.

#_ as part of a method name doesn't  work in Squeak and is very ugly
in my opinion too.

#basic as a method prefix is used to show that a method is private and
that it should not be overridden (something like private final in
Java).

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > > Accessors of the form #setSomething: are private by convention, you
> > > should not call them directly unless you exactly know what you are
> > > doing.
> >
> > Really? Interesting, I hadn't heard about that in other flavours of
> > Smalltalk. Is it a general Squeak convention or a Seaside convention?
>
> No, this is Kent Beck, Smalltalk Best Practice Patterns: Constructuor
> Parameter Method. (page 25)

Ah, I didn't remember that one... heh, guess it's hard disagreeing
with Kent Beck.

> Also check out the Seaside coding-conventions:
> http://www.seaside.st/community/conventions

Interesting, thanks for the link. Offhand, everything seems sensible
except the last point of the 'Formatting' section imho, but I guess I
could learn to live with it :-/

> > Shouldn't #setName: be in the 'private' protocol then, rather than in
> > 'initialization'?
>
> The initialization protocol is private, it should never be called from outside.

I'm used to it being called 'initialize-release', but that may be a VW thing...

> > That's how I was taught to do it, way back when,
> > and/or to add a "private" method comment for unsuspecting browsers.
> > I've encountered other conventions, like #_name:, #privateName: or
> > #basicName: rather than simply #name:, for various purposes, but not
> > the #setSomething: one.
>
> #_ as part of a method name doesn't  work in Squeak and is very ugly
> in my opinion too.

I agree, it seems very... C-ish.

> #basic as a method prefix is used to show that a method is private and
> that it should not be overridden (something like private final in
> Java).

Hmm, different again from what I remember - the #basic... methods I've
seen were simply used to access a "naked" instance variable when the
provided public accessor was executing some code before returning the
instance variable, and was generally placed in 'private' or
'privileged' protocols.

> Cheers,
> Lukas

Thanks, very interesting stuff. Guess Smalltalk (and especially
Squeak) continues to evolve when you look the other way for a few
years. =o)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

The problem embarassingly turned out to be browser caching. The only way to
turn this off in Firefox is through
    about:config
    ---  network.http.use-cache = false

Changing the base url had the effect of invalidating that cache, so I
incorrectly thought that hacking '/seaside/' somehow caused the problem.

I am back in business with the strictly unsupported '/seaside/' hack, far
slower page loads, and reliable css-updates.

Thanks Lukas, Keith, Amos.



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> No, this is Kent Beck, Smalltalk Best Practice Patterns: Constructuor
> Parameter Method. (page 25)
>
>  
I have been wanting to ask this for a long while...

If we are following best practice patterns how come "Constructor Method"
page 23 of same book answering the question "how can I create a valid
instance as simply as possible"  has been abandoned.

I am speaking of WASession-application:

cheers

Keith
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

itsme213 wrote:
> The problem embarassingly turned out to be browser caching. The only way to
> turn this off in Firefox is through
>     about:config
>     ---  network.http.use-cache = false
>
> Changing the base url had the effect of invalidating that cache, so I
> incorrectly thought that hacking '/seaside/' somehow caused the problem.
>
>  
With a bit of poking around you can get file library to send css flagged
as non-cached

In the Jetsam library there is a WANonCachedDocument class which
WAFilesLibraryPlus uses by default during development. (Perhaps I should
switch this off automatically on deployment)

Keith

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I am speaking of WASession-application:

The way the session stores its application is an internal
implementation detail of the framework. Seaside instantiates and
initializes the session objects for you and this is usually something
you shouldn't bother about.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote: Unfortunately Seaside is rarely the be-all and end-all of an application
it is merely one front end presentation of that application.

Given that I have made a design choice to have my applications present
all of their settings in seaside/config when I want to do something in a
workspace, or offline script I need to instanciate a mock session so
that I can work in the context of the chosen application and its
settings. This used to be just a little bit simpler and has become a
very common pattern for me. It is used in a number of places:

The 'pier' and 'magma' control panels which appear as configuration
application plugins are rendered in a session of the configuration app,
while they operate upon the preferences and data structures of a mock
session of the actual app which they control.

The Jetsam package defines WASession forApp: name during: [ ]

This provides the ability to run code in a workspace in the context of a
chosen seaside application (i.e. the settings and WACurrentSession is
defined while in the block).

Finally Magma-seasideHelper uses a variant of this,  "WAMagma forApp:
name", in order to access or commit to the database as configured in
seaside/config.

So thats 4 use cases which is sufficient for me to think that putting
#application: back is worthwhile, which indeed I do in Jetsam

I have separated Jetsam out into some separate packages, so that the
Helper framework is available as a separate entity. Please would you
consider adopting this properly into the mainstream 2.9 release.

many thanks in advance

Keith
 
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:

>> and totally removed by default.

Lukas> I find it more appropriate to have the /seaside prefix by default. I
Lukas> have many web applications running on my development and deployment
Lukas> machines and this helps a lot to integrate with other applications.
Lukas> Changing it does not make anything easier, it just makes 5 years of
Lukas> Seaside blogs and tutorials obsolete.

Well, I can understand you having a personal preference to always have
/seaside in the URL, but it appears that it would be courteous to support the
requests of some of your customer base (me included) to be able to set
it to anything else we choose as well, empty if needed.

As a specific data point, I have a legacy application that requires a
particular URL, but has low enough traffic that I don't want the added
complexity of an Apache front proxy.  This is the perfect case for me to set
the /seaside prefix to the legacy app's prefix (in this case, empty), and use
it as is.  I was planning on using setName: for that, because it wasn't in the
'private' category, and it works. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Lukas> Changing it does not make anything easier, it just makes 5 years of
> Lukas> Seaside blogs and tutorials obsolete.
>  
Why should it? Removing seaside from the url need only be optional.

And what of the five years of requests in [hidden email]
email list requesting this feature?

Uncomfortable, and suboptimal as it may be it is an essential
requirement to be able to serve fo whatever url be required. I am in the
same position, and "remove seaside from the url" has been on my to do
list for 6 months, as a requirement from my client.

Please include this feature as a properly supported option.
> Well, I can understand you having a personal preference to always have
> /seaside in the URL, but it appears that it would be courteous to support the
> requests of some of your customer base (me included) to be able to set
>  
well said Randall

cheers

Keith

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Lukas> Changing it does not make anything easier, it just makes 5 years of
> > Lukas> Seaside blogs and tutorials obsolete.
>
> Why should it? Removing seaside from the url need only be optional.

You suggested to totally remove it by default.

> And what of the five years of requests in [hidden email]
> email list requesting this feature?

The point is that Seaside is not a web server. Of course we could add
smart dispatchers, proxying, virtual-hosts, whatever ... but we would
never reach the speed, quality and functionality of something like
Apache. I also don't want to bloat the code with things that are not
easily portable across different Smalltalk dialects and web server
front-ends.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Lukas Renggli" <[hidden email]> wrote in message

> You suggested to totally remove it by default.

My mistake, seen from just my narrow needs :( I agree with Lukas that just
making it configurable would be the right solution.

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:

Lukas> The point is that Seaside is not a web server. Of course we could add
Lukas> smart dispatchers, proxying, virtual-hosts, whatever ... but we would
Lukas> never reach the speed, quality and functionality of something like
Lukas> Apache. I also don't want to bloat the code with things that are not
Lukas> easily portable across different Smalltalk dialects and web server
Lukas> front-ends.

I'm not asking for any of that.  Just don't make setName: '' break (since
it already works) or give me another public interface to do that.

I also have a suggested refactoring for
WADispatcher>>handlerForRequest:relativeTo: - it's a complex method
with two calls to "WANotFoundHandler new" making it not very subclassable or
pluggable.  Could you replace those with something like "self notFoundHandler"
or something, so I could provide my own not-found-handler class?  A preference
would even be better.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

+ 1 from me, if it was configurable with 'seaside' by default I would be
fine with that. You could then let people make it empty/nil to suppress
the prefix altogether or change it to be 'pinkelephant' if they cared
to.

-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.
just
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside