1 Mar
2009
1 Mar
'09
4:55 p.m.
On Sun, 2009-03-01 at 16:37 +0100, Tudor Girba wrote:
Well, line 1 of PRJavascriptSupport>>pierJs says
Event.observe(window, "load", function() {
So I get an Event.observe is not a function if the SULibrary is
not preceeding the PRJavascriptSupport in the application settings.
Norbert
Hi Norbert,
My answers are inlined below.
Hmm, then it seems I do not understand your situation. Let's try to
clarify it a bit.
When you say broken, what exactly do you mean? Of course that the
layout and colors are not going to be the same, but the forms will
still have proper dimensions, which is what seemed to have spawned the
first problem.
We have a layout that displays green header that spawns the whole
browser width. In the header there is from left to right: a logo,
navigation links, an orange box and a search field. As soon as
I include the blueprint stuff the header gets a vertical offset
(there is white space between the browser top and the header). The
logo and navigation links are displayed correct but the orange box
and search field are displayed below the header. So I'm not sure if
blueprint does some global stuff that interferes our layout. And
I don't know what can be the cause of this.
The
default look and feel is based on the blueprint css framework.
This is provided via the PRBlueprintLibrary library. This framework
is
a generic one and it mostly provides css classes for laying out the
pages into columns. It also provides some default styles for basic
html tags like textarea or input which is what gets eventually used
for editing pier. See the project page for more details:
http://code.google.com/p/blueprintcss/
The CSS that is specific to the look and feel of the default webpage
is available to you via the Edit Design command. This is
where .footer
and .header is defined. So, you have complete control over the look
and feel without removing the libraries. The provided css features
some commented to point out where the large parts out. So, all you
have to replace the Pier css (or part of it) with your css in the
provided area and to modify the template accordingly.
Is this helpful?
Not really. I have to investigate this somewhat deeper. I understand
what you are trying to say. But in my case it is different. If I
have the libraries loaded and in "edit design" the css removed
completely the design of my page is broken. So there are things that
conflict. I'm not that good in css but I hope I'll be able to figure
it out. I even did a dummy component inside the page that does
updateRoot: to be sure mine is the last loaded.
The last to get loaded is the css in Edit Design. So, why is it not
enough to add your definitions at the end of that file?
Usually a css comes with an html template. In this case, you would
have to also change the structure of your environment anyway, and then
it would fit with your custom css definition. And as the basic
functionality of Pier does not depend on the css that is in Edit
Design, you should not have a problem with that.
I tested all of this by changing the enviroment to include only my
stuff and the css as well. I checked with the current markup we produce
in the standalone application. Beside the css classes pier puts in
the body element it is the same. Only the existance of blueprint
changes the effect. But I think I have to boil this down myself.
Btw. some trivial things to note:
If you try to remove the css in "edit design" completely you get an
MessageNotUnderstood: UndefinedObject>>asByteArray
Thanks for reporting, I added an issue here:
http://code.google.com/p/pier/issues/detail?id=79
And you have to make sure that SULibrary is added
before
PRJavascriptSupport.
I am not sure I understand this. Why do we have to make this sure? In
fact, you do not need SULibrary at all, except for debugging seaside
behavior. As for PRJavascriptSupport, Lukas has removed all
dependencies to the Prototype and Scriptaculous, so this Library will
not be needed either.
Norbert
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
On 28 Feb 2009, at 17:59, Norbert Hartl wrote:
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki While testing how hard it will be to bring my
site
into pier I discovered some css class clashes. For
people it is quite normal to assign classes like
header, footer and the like.
In my opinion a cms like pier should try to step
out of the way of any usage conflict. Therefor I
would propose to namespace the css classes. A
pr_header, pr_footer will do I think.
Or do I missunderstand something completely? For me
it was not possible to reconstruct our layout without
haveing to remove all librares for the application. But
then it is tedious to work with pier as the edit boxes
and stuff are too small.
What is the best approach to bring in the own developed
design and having pier still functioning?
thanks,
Norbert
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
www.tudorgirba.com
"Being happy is a matter of choice."
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki