Hi,
I'm investigating using Pier to develop a site where registered users can
have one or more associated projects. These projects should be bookmarkable.
A good analogy would be the projects in squeaksource. Using that analogy how
would one go about developing something like squeaksource in pier? Would the
page structure expand as users registered new projects? For example:
root
|--- home
|--- users
|--- projects
|
|--- Announcements
|--- Gofer
|--- Helvetica
.
.
|--- Pier
| --- Wiki
| --- Blog
| --- News
| --- Versions
| --- Latest
where each of the projects includes it's own sub-pages;
wiki/blog/news/versions/latest etc.
As the number of projects grew, would using Pier like this cause any
memory/performance issues? Any other thoughts for how to structure a site of
this type.
Thanks
Nick
At 20:14 18/01/2010, Nick Ager wrote:
>1) Create a Pier hierarchy of pages which mirror the model and
>potentially duplicate the data within it
>2) Use the Pier page hierarchy as the model
>3) Use the model to dynamically create Pier pages during a request.
Hi Nick,
I'm developing a system where Pier is successfully used following an
approach which is close to (1), but there is no duplicated code/data,
etc. ) To keep the analogy with MVC, I use Pier as View & Controller,
but not as Model. The PRStructure hierarchy is used as an
"organization" medium for parts of my business model that need
visualization and user interaction. The latter are implemented by
PRViewComponens (WAComponents).
With your approach (2) there is indeed a risque of mixing model and
view, but all depends on your application domain. As already stated
by Lukas, if your business model elements "naturally fit into a
tree", then it would probably be "natural" to adopt this approach.
I won't recommend the 3rd approach since inconsistent with the design
of Pier, and unnecessarily complicated.
Hoping this helps,
Regards,
Reza
Hi Lukas,
Apologies for repeating myself, but I'm still not sure how to solve this
problem, or why you don't see it...
Reiterating; does this test assert on your machine?:
| stylesheetFile stylesheetContents rendererResult |
stylesheetContents := '/* a style sheet */'.
stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css';
mimetype: 'text/css'; contents: stylesheetContents.
rendererResult := WARenderCanvas builder render: [ :html |
html render: stylesheetFile file contents].
self assert: rendererResult = stylesheetContents
To reproduce the problem with Pier, register a Pier instance with:
PRPierFrame registerAsApplication: 'pier' kernel: (PRKernel new root:
(PRPage new title: 'test title'; contents: 'Pier on Seaside 3.0'; name:
'testPage'); name: 'testKernel').
browse to: http://localhost:8080/pier/environment/style.css, results in:
#[47 42 32 98 108 117 101 112 114 105 110 ...
Any more thoughts?
Nick
2010/1/12 Nick Ager <nick.ager(a)gmail.com>
> I've tried to encapsulate the problem in a test:
>
> | stylesheetFile stylesheetContents rendererResult |
> stylesheetContents := '/* a style sheet */'.
> stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css';
> mimetype: 'text/css'; contents: stylesheetContents.
> rendererResult := WARenderCanvas builder render: [ :html |
> html render: stylesheetFile file contents].
> self assert: rendererResult = stylesheetContents
>
> In my image the assertion fails. If I change ByteArray>>greaseString to
> return self displayString the assertion succeeds.
>
> Does that help?
>
>
> 2010/1/12 Julian Fitzell <jfitzell(a)gmail.com>
>
> I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet.
>>
>> Julian
>>
>> On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
>> > #[100 101 98 117 103 103 105 110 103], but this method is never called
>> > when I browse Pier.
>> >
>> > Lukas
>> >
>> >
>> > 2010/1/12 Nick Ager <nick.ager(a)gmail.com>:
>> >> Hi Lukas,
>> >> Don't think the browse cache is the problem. What do you get with:
>> >> #[100 101 98 117 103 103 105 110 103] greaseString
>> >> on my image the result:
>> >> '#[100 101 98 117 103 103 105 110 103]'
>> >>
>> >> 2010/1/12 Lukas Renggli <renggli(a)gmail.com>
>> >>>
>> >>> > Does your the implementation of
>> >>> > ByteArray>>greaseString match this:
>> >>> > ByteArray>>greaseString
>> >>> > "ByteArrays should not automatically be converted to Strings. You
>> should
>> >>> > use
>> >>> > a GRCodec for this."
>> >>> > ^ self printString
>> >>>
>> >>> Yes.
>> >>>
>> >>> > or does your image have an implementation of ByteArray>>encodeOn?
>> >>>
>> >>> No.
>> >>>
>> >>> Maybe you should clear your browser caches?
>> >>>
>> >>> Lukas
>> >>>
>> >>> > 2010/1/11 Lukas Renggli <renggli(a)gmail.com>
>> >>> >>
>> >>> >> Has this been fixed, because it works here?
>> >>> >>
>> >>> >> Lukas
>> >>> >>
>> >>> >> 2010/1/11 Julian Fitzell <jfitzell(a)gmail.com>:
>> >>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas?
>> >>> >> >
>> >>> >> > Julian
>> >>> >> >
>>
>
I've changed code in a couple of methods, where the code within a method
generating javascript output has changed from:
id printString
to:
id greaseString
The problem arises as the string is no longer surrounded by single quote
marks, resulting incorrect javascript. The methods effected are:
Pier-EditorEnh PRChangeCommand>>updateRoot
Pier-Documents PRDocumentWidget>>renderEditOn:
My initial fix was to simply add the single double quote as:
PRDocumentWidget >>renderEditOn: html "Pier on Seaside 2.8"
| id |
self halt.
html textArea
value: self text;
class: 'wiki-inline';
id: (id := html nextId);
callback: [ :value | self text: value ];
onKeyUp: 'pier_document_widget_update(' , id printString , ')'.
self session
addLoadScript: 'pier_document_widget_register(' , id printString , ')'
becomes:
renderEditOn: html "Pier on Seaside 3.0"
| id |
self halt.
html textArea
value: self text;
class: 'wiki-inline';
id: (id := html nextId);
callback: [ :value | self text: value ];
onKeyUp: 'pier_document_widget_update(''' , id greaseString , ''')'.
html document
addLoadScript: 'pier_document_widget_register(''' , id greaseString , ''')'
However examining the code which executes when printString is called I
noticed that it also escapes any quote marks in the string passed. On
reflection I found the method asJavascript which appears to do the right
thing. I've removed my extra speech marks, changed greaseString to
asJavascript, and tested and all appears functional again. Have I found the
right method?
I've saved an initial port of Pier-Documents and Pier-EditorEnh for Seaside
3.0 to the pier2 repository. I've focused on making essential changes to
ensure that the packages work on Seaside 3.0, rather than all the changes
necessary for the packages to work in other dialects.
One of the changes I made was to remove the image caching as:
| cache |
cache := #(nil) beMutable.
(cache at: 1) isNil ifTrue: [
cache at: 1 put: #(137 80 78 ...
^ cache at: 1
becomes:
^ #(137 80 78 ...
rational: beMutable is no longer defined and the change appeared to be
inline with changes made to images elsewhere.
Be careful if you're trying to diff in MC, I found that MC disappeared into
a processing back-hole when I tried to diff PRHaloScripts>>haloPng
BTW I don't understand the original caching code, but am intrigued by it. Is
it explained anywhere?
Nick
Pier 1:
----------
I uploaded a new package "Pier-Setup-razavi_acm_org.72" to:
http://source.lukas-renggli.ch/pieraddons.
For modification details, please see the package comments.
Pier 2:
---------
I loaded the same package into the Pier 2 image that I mentioned in a
previous email this morning. All of the three distributions seem
working fine. However, I had to hack the code in one method as
follows (added calls to #asString and #asByteString]):
GRPharoUtf8CodecStream >> nextPutAll: aString
binary
ifTrue: [ stream nextPutAll: aString asString ]
ifFalse: [
aString asString isByteString
ifTrue: [ self encodeFast: aString
asString asByteString]
ifFalse: [ self encodeDefault:
aString asString] ].
An open (Seaside 3.0 ??) issue:
----------------------------------------------
When hot switching distributions via the Design Chooser interface
in the Home page, the following call sequences raises an exception:
WAApplication (WARegistry) >> urlFor:ifAbsent:
WAApplication (WARequestHandler) >> url
WADispatcher >> urlFor:
WADispatcher >> nameOfHandler:
However, by forcing the navigator to point to
<http://localhost:8080/pier>http://localhost:8080/pier, the new
distribution is launched and seems fully operational.
Cheers,
Reza
Hi,
I've turned my attention to merging the latest code in the add-ons, which
resulted in some questions:
* Pier-Blog - easy merge, no conflicts
* Pier-Book - 9 conflicts - the merge didn't look straight-forward so I
thought I'd leave it to someone with more intimate knowledge of the code and
changes...
* Pier-LinkChecker - I couldn't find the trunk version of this package - I
didn't spot it in pier or pieraddons repositories
* Pier-Pharo-Persistency - I couldn't find the trunk version. Is it a rename
from Pier-Seaside-Persistency?
* Pier-Seaside-Persistency - I'm running under Pharo so I'll leave this to
someone else.
In summary I only merged Pier-Blog
On the pier seaside 3.0 code-branch, browsing to:
http://localhost:8080/pier/environment/style.css, results in:
#[47 42 32 98 108 117 101 112 114 105 110 ...
rather than:
/* blueprint patches */
h1, h2, h3, h4, h5, h6 { margin: 0; fo....
This issue is caused by a change in how ByteArray is rendered in Seaside 3.0
(the problem was also present prior to merging the latest Pier code):
seaside 2.8
Object>>encodeOn: aDocument
aDocument print: self displayStriong
seaside 3.0
Object>>encodeOn: aDocument
aDocument print: self greaseString
ByteArray>>greaseString
"ByteArrays should not automatically be converted to Strings. You should use
a GRCodec for this."
^ self printString
changing ByteArray>>greaseString to return self displayString fixes the
problem. However I can see there are a number of ways to fix this, and as
it's such a low level change I'm sure there was a good reason for
displayString to be changed to printString. Thoughts?
At 13:25 12/01/2010, Lukas Renggli wrote:
>Pier-Setup is used to build the one-click images. It is not really
>ment to be used as an end-user tool.
I understand, but I find it particularly useful also for setting
rapidly an environment for testing ideas in the context, etc.
>These two are broken in Pier 1. If you have a look at that could you
>first fix them for Pier 1?
Sure. I'm going to look at that.
Later,
Reza
Hello and Happy New Year to the list.
Thank you Julian, Nick, and Lukas for the port to Seaside 3.0.
I'd like to give a hand to finalize this port, and started by
"Pier-Setup" as follows:
- Dependencies (in addition to the core Pier packages): Pier-Blog,
Pier-Documents, Pier-Google, and Pier-Book.
- Starting point: http://hudson.lukas-renggli.ch/job/Seaside%203.0/.
- Loaded from http://source.lukas-renggli.ch/pier2:
Pier-Blog-NickAger.135 and Pier-Documents-NickAger.17.
- Loaded from http://source.lukas-renggli.ch/pieraddons:
Pier-Google-lr.16, Pier-Book-lr.112, Pier-Setup-lr.71. Had just to
edit one method (please see the attached file).
- Executed "PRLoader setupPier"
- Pointed to <http://localhost:8080/pier>http://localhost:8080/pier.
As far as I could test, it just works fine, including Gadgets.
- Loaded Pier-Design-lr.8 to have the "Edit Design" command. It
works, except for the stylesheet rendering issue already reported by Nick.
Questions:
1) Would it make sense to isolate PRBookDistribution in a separate
package, to avoid the current dependency between Pier-Setup & Pier-Book?
2) Would it make sense to have a PierBasicDistribution, without
dependencies to Pier-Blog, Pier-Documents, Pier-Google?
(PierDistribution could obviously then be a subclass of PierBasicDistribution).
3) Should I upload the above packages?
3.b) If yes, in which repository:
http://source.lukas-renggli.ch/pier2 or
http://source.lukas-renggli.ch/pier2-addon? For the moment all core
and addon packages are in the same repository, which is somehow more
practical compared to Pier 1.
Remaining issues:
A) Load scripts in PRLoader need to by adapted to the new repositories.
B) Testing PREventDistribution and PRBookDistribution.
I'm going to take care of (B).
Cheers,
Reza
