Hi,
is there any photo gallery available for Pier? I mean a widget where I
could upload pictures and they are rendered in a nice way. I started
one 4 years ago but I abandoned it.
Bye
--
Damien Cassou
http://damiencassou.seasidehosting.st
I'm having little success with this. Nick Ager's recent documentation
regarding Pier Admin has been very helpful in many other respects and
has inspired me to pursue Pier further, but embedding a Seaside
component or application seems to elude me.
If I create a small Seaside application, how do I reference it so that
it embeds in my blog? A small example sure would help.
Many thanks.
The Pier-JQueryMobile-Core package, along with the attached 3 changesets
(which override Pier/Magritte methods), need to be installed. Then run:
PRJQueryMobileDistribution new register
It's unfortunate that the changesets are needed. Maybe someone has a
better way.
Also attached are two screen shots of what you should see. You should
have a default jQueryMobile UI for Pier.
Hi,
I vaguely remember some work was undertaken making a mobile view for Pier.
Is it still available? How did/does it work? Custom templates, views?
Did/does it select the view based on user agent?
I was wondering about using jQueryMobile to create a mobile view - though
as I write this perhaps a mobile rss reader and using Pier's rss support
would fulfil a similar purpose? Thoughts?
Cheers
Nick
Hi,
Since my initial post about Pier Admin I've fixed numerous bugs, added
documentation and simplified the configuration. The WYSIWYG parser now
parses tables, embedded lists, book index and reference links. To the best
of my knowledge it should either understand or preserve all Pier markup.
Let me know if not.
I've also created a new book view - BOAggregatedView. From it's comment:
I display my own structure and all my child structures if I answer true to
> #isPublication. I format publication numbers as the default book template.
> I provide an edit link for each child structure.
The view allows you to view all the contents of a chapter or section at
once. I'm couldn't find anything similar already in Pier, is there?
I've discovered some cool Pier-EditorEnh functionality that I didn't know
existed. If you click on a link button (in the enhanced wiki editor)
without any text highlighted a popup window displays the site map and the
available value links. Very cool. There was a small bug which prevented it
working in Pier2, which should now be fixed.
As ever Pier admin can be installed with:
Gofer it
> renggli: 'pier2addons';
> package: 'ConfigurationOfPierAdmin';
> load.
> ConfigurationOfPierAdmin loadBleedingEdge.
Let me know how you get along - feedback always appreciated.
Nick
Hi,
For all the Pier distribution I've checked I've noticed that for each
request the stylesheet was being served from a new Url. The relevant
implementation is:
MAFileModel>>url
"Answer a link to a request handler for the given file."
| handler |
handler := MAFileModelHandler on: self.
^ WACurrentRequestContext value registry
register: handler;
urlFor: handler
Which means that for every request for a file model's url, a
new MAFileModelHandler is being created and registered.
The result is:
* The browser never caches the stylesheet
* Each page request unnecessarily adds to the application's collection of
handlers.
Note: This is a generic Pier issue for PRFile requests, unless the url
includes the query ?view=PRDownloadView OR MAExternalFileModel class
baseUrl: has been defined).
One solution would be to add ?view=PRDownloadView to the url for stylesheet
requests or possibly for all file requests (modify MAExternalFileModel>>url
to add ?view=PRDownloadView).
However pondering the problem I've prototyped a solution in which PRFile
have a custom view component "PRFileView" which responds with it's
associated PRFile file directly, rather than delegating
to MAFileModelHandler. The logic is that, by default, PRFile>>#url responds
with a fully qualified path to itself within the pier structure
e.g. /pier/template/style.css then PRFileView>>#initialRequest checks the
request to see if it matches the mime-type of it's associated PRFile's
mime-type, if so it will respond true to PRFileView>#isFullResponse and
serve the file directly in PRFileView>#respondUsing:
MAExternalFileModel class>>#baseUrl still works as intended and
MAFileModel>>#url (and friends) remains unchanged.
The result appears to be a neater solution
than modify MAExternalFileModel>>url to add ?view=PRDownloadView, but I
might be suffering from implementors bias :-)
I thought I should check that:
1) people think it looks like a sensible fix and improvement
2) if (1) then whether I should delete MAFileModel>>#url (and friends),
deprecate them, or leave them as is.
Thanks
Nick
