Brad,
Are you even getting the default Pier styles? If not, follow my instructions in my previous email in regards to this matter. That should at least get you the default Pier look and feel.
As to using Seaside's FileLibrary for your own style sheets, I haven't figure that one out either. However, I just did a search on the web and came up with this (I haven't tried the instructions in the link, yet, so no guarantees):
http://lists.squeakfoundation.org/pipermail/seaside/2006-May/007777.html
-Bill
----- Original Message ----
From: Brad Fuller <brad(a)sonaural.com>
To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
Sent: Saturday, February 17, 2007 3:34:32 PM
Subject: Re: Pier Stylesheets - Help!
Lukas Renggli wrote:
> Hi Brad,
>
>> How come nobody has PRPierLibrary>>styleCss method?
>> This class seems to have all of the default css styles of Pier. Why I
>> get absolutely no stylesheet at all, I don't know.
>
> sorry, I am on a trip and I couldn't replay earlier. I don't exactly
> understand why the thing with the style are not working.
>
> There are I few things that might be the problem:
>
> 1. The 2.7 branch of Seaside made some big changes in that area (and
> there are a few more to expect), they do work fine in my image but
> they are mostly untested.
>
> 2. Pier and Magritte require the latest version of Seaside (I think
> you use those).
>
> Maybe you want to use the version of Pier from SqueakMap, as it
> builds you an image with the right version of Seaside, Magritte and
> Pier that is knows to work well together. It is not bleeding edge,
> but it is fresh and should be fairly easy to update later on.
Hey, thanks for the reply, Lukas.
Well. that's where I started ;-) Even at that point, if I remember
correctly, I had "styleCss" method and not "style" method that pointed
to an actual file (your file, I believe on the Internet.)
I really wanted the newest blog plugin and a better way to handle images
- which I thought FileLibrary was to do.
It would be good if there was a proper way to update. I certainly don't
know if that's the problem. That's what Keith seems to be headed for.
Well.. I'm almost there... so maybe I can druge along with the member's
help and see if I can get this puppy running like it should be!
I think I need to find out how FileLibrary works. Or at least, find out
how I can serve png files for the css.
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
I think you need to go to the "configure" page for Pier (accessed from the bottom of the Pier pages), and add "PRPierLibrary" as a library, then select "PRPierLibrary" from the File Library pull down under the "Pier" configuration section.
-Bill
----- Original Message ----
From: Brad Fuller <brad(a)sonaural.com>
To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
Sent: Friday, February 16, 2007 11:58:49 PM
Subject: Pier Stylesheets
Looking through the various Pier documentation, I see that code has
changed and thus there are several different explanations of how to
change stylesheets. I want to use a different css stylesheets but I
can't find out where to change it/them. Isn't there one place to point
Pier to one stylesheet?
BTW: for some reason, I have no style sheet at all for Pier. I don't
know what I did, but I didn't edit any code... I must have loaded a new
version of some package. Anyway, unless it stomped on something else, if
I can learn where to change the stylesheet pointer, It'd give me a start.
thanks,
brad
--
brad fuller
http://www.Sonaural.com/
+1 (408) 799-6124
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
____________________________________________________________________________________
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
Hi,
my VW Smallwiki (not shure which version, the "stable" release from
Bern Store) is running on a Win2k Server. I can connect under
localhost:8080, but I can not acces from extern (over the internet).
Server host and server baseBath are set to the www adress of my server.
What is wondering me is that it works locally but not over internet.
Before this, a Squeak Smalltwiki was running successfully with the
same configuration.
Is there any problem of the VW version ?
Regards
Hans
>> How do you scope the language? I don't see that in the implementation
>> in Squeak of System-Localization. To make it even works I have to say
>> that we have even Web application that can have different parts of
>> the same session in different languages ;-)
>
> In most cases I use only one language so standard Squeak translation
> mechanism is OK ;-) But where I need many languages, I use special
> "literal" where I define all translations together. It's better for
> mainenance.
Certainly, I completely agree. What I do not understand is the way
how the #translated mechanisme works in Squeak. As far as I can see
there is nothing like a dynamic scope but just a global variable,
something that certainly does not work in the context of a Web
application.
>> > So I think that the standard
>> > #translated message will be the best solution and the final
>> > translation mechanism will be then dependent only on user's choice
>> > (for example user-modified implementation of #translated message).
>> > What do you think?
>>
>> I don't see, but if you change #translated to use a dynamic variable
>> you break all the Squeak tools that use #translated. No?
>
> The exception based dynamic variable (for current language) returns
> nil in case it is not defined in current stack. So then the default
> implementation can be used.
Yes, that's what we do in productive applications. In development
mode the translated string object can display a red warning and
potentially a link to an editor to translate the actual string ;-)
> Now the only way how to create localized Magritte and Pier
> applications is to modify their source code. We should solve it
> somehow.
Do you really think so? At least for Magritte there shouldn't be too
much hardcoded strings anymore, as I use it in several productive
multi-lingual applications. For Pier this is indeed a different story.
Unfortunately all the labels and comments in the descriptions are
hardcoded, due to the fact that I only used it in english contexts.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
>> yes I noticed as well. Maybe Philippe knows more about it, he
>> implemented MAToManyScalarRelationDescription.
>
> It used to work in:
> Magritte-Model-lr.235
> Magritte-Tests-lr.102
> What changed in the mean time that could have caused it?
I don't know, nothing really. Have a look it is really strange, it
works in the debugger but not if the test is run in the test-runner.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi Pavel,
> Ok. There's the next very strange bug in Magritte. When you try to run
> tests, one fails
> (MAToManyScalarRelationDescription>>testCopyReference). String
> descriptions have different uuids but only for first time. If I try to
> evaluate this comparison again, it returns true (Sqeuak 3.9).
yes I noticed as well. Maybe Philippe knows more about it, he
implemented MAToManyScalarRelationDescription.
>> > If you'll agree, I would like to prepare Magritte and Pier for
>> > translation into other languages. That means mostly simple
>> adding the
>> > #translated messages to string literals but in some cases it
>> will be
>> > more complicated.
>>
>> I don't think that is a good idea for two reasons:
>>
>> 1. The #translated mechanism is specific to Squeak and wouldn't work
>> with the ports to other dialects.
>>
>> 2. The #translated mechanism is global to an image. We have several
>> web applications using Magritte where the language (german, french,
>> italien, english) is defined per session and can be even switched on
>> the fly. I don't see how that would work with #translated?
>>
>> Please correct me if I misunderstood your proposal.
>
> I used it in ShoreComponents and there were no problem with VW port
> (even Michel didn't tell anything against it). On the other hand it
> then uses only dummy implementation without translation.
How do you scope the language? I don't see that in the implementation
in Squeak of System-Localization. To make it even works I have to say
that we have even Web application that can have different parts of
the same session in different languages ;-)
> Per session translation can be done similarly to WADynamicVariable
> mechanism. How do you solve translations now? The sending of some
> message to string literals is quite general solution. We may name it
> for example magritteTranslated but that it will mean that this message
> will be part of the Magritte package.
At netstyle.ch we use a special object that represent a translated
string. This object can be used anywhere as a replacement for a
string, as it supports the same protocol. When a string is rendered
(#renderOn:) it does the lookup and displays the right translation
lazily. The language context is defined using a dynamic variable.
> So I think that the standard
> #translated message will be the best solution and the final
> translation mechanism will be then dependent only on user's choice
> (for example user-modified implementation of #translated message).
> What do you think?
I don't see, but if you change #translated to use a dynamic variable
you break all the Squeak tools that use #translated. No?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi Pavel,
> there are some missing classes in the latest published version of
> Magritte. MAUnlimited class >> initialize fails because classes
> M2PositiveUnlimited and M2NegativeUnlimited don't exist.
thanks for reporting, this issue should be fixed with the latest
commit. These changes are not used yet, it is just a first step
towards propre multiplicities. The latest commit also contains a
change that avoids recursion when validating recursive graphs,
however it is untested for now.
> If you'll agree, I would like to prepare Magritte and Pier for
> translation into other languages. That means mostly simple adding the
> #translated messages to string literals but in some cases it will be
> more complicated.
I don't think that is a good idea for two reasons:
1. The #translated mechanism is specific to Squeak and wouldn't work
with the ports to other dialects.
2. The #translated mechanism is global to an image. We have several
web applications using Magritte where the language (german, french,
italien, english) is defined per session and can be even switched on
the fly. I don't see how that would work with #translated?
Please correct me if I misunderstood your proposal.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
hi
in one of my application I have an object that represent a
bibliographic entry.
I has a set of fields that really depends on the type of the entry.
An article will have different fields than a journal....
Now how could I use magritte to describe such object.
Should I have a dictionary that returns MAdefinition at the object
level (the table could be shared between all the instances
of the classes.
Stef
Hi,
I have a problem with infinite recursion in Magritte. This
problem was discussed on this list before. The problem is
having circular dependencies in descriptions.
I tried to utilize the hints from Lukas to use
reference: (MADynamicObject on: (MyObject
descriptionsWithoutReferences))
Having a descriptionsWithoutReferences introduces an infinite
loop by itself. So I changed it to getDescriptionsWithoutReferences.
This prevents the infinite recursion but doesn't work really
well with the ActiveRecord implementation from Ramon (at least
in my case).
So I decided to change Magritte not to do infinite recursion. I
changed
MADescriptionBuilder>>for: anObject
^ cache at: anObject ifAbsent: [
cache at: anObject put: true.
cache at: anObject put: (self build: anObject).
].
I know this looks very ugly but I don't have an idea how to do
this more elegant. My question is if this change introduces
problems elsewhere in Magritte? I don't like to fix one problem
by creating another one :)
thanks,
Norbert
