Hi,
I've rearranged some of my Wysiwyg Pier code into new repositories:
* Pier-FileUpload-Wysiwyg - Wysiwyg editor with file upload support in a
standard image
* Pier-FileUpload-Common-Wysiwyg
* Pier-FileUpload-Nginx-Wysiwyg - Wysiwyg editor with file upload support
using the Nginx web-server to stream file directly to disk and provide
upload progress support.
So the Pier-NginxFileUpload-Wysiwyg repository in
http://source.lukas-renggli.ch/pier2addons is now redundant. Any chance
someone with admin access could delete all the versions of that package from
the repository.
The other repositories remain the same:
* Pier-Wysiwyg
* Pier-Tests-Wysiwyg
The Wysiwyg editor is nearly ready for a 1.0 release. It now includes
file-upload and a site-map drop-down to provide Wysiwyg support for creating
internal links and embedding images. I'll update the
ConfigurationOfPierWysiwygEditor and probably ConfigurationOfPierAddOns2
ASAP to make it easy to install. It's probably best to wait for the
ConfigurationOfPierXXX updates as there are some tricks for the file-upload
support - a WASystemConfiguration derived class and a WARequestFilter.
I'd love to try the Wysiwyg editor with a large set of Pier content to test
if it's ready for prime-time. Anyone fancy trying it?
Cheers
Nick
Hi Lukas. I was serializing Pier kernels with Fuel and I started to face
problems with Magritte proxies. Since I have no idea how/why they are use, I
need to ask a couple of question. Imagine I want to serialize a graph (like
a Pier kernel) that contains instances of MADynamicObject, like
MAMultipleOptionDescription new
default: [ self defaultViewClasses ] magritteDynamicObject;
options: [ self defaultViewClasses ] magritteDynamicObject;
....
So the questions are:
- When I MATERIALIZE the graph, would you like to
a) still have the proxies exactly as it was during serialization ?
b) or would you expect that objects refer directly to the target of the
proxy (proxies do not even exist) ?
If you want a) then there are problems that I have to fix because for
example I put objects (proxies) in a IdentitySet/IdenitityDictionary (which
of course #== is not intercepted by the proxy) but then when I do
#instVarAt: or #basicAt: etc, from the serializer, it intercept the messages
and forwards to the target. This makes things complicated in Fuel but we can
solve it.
b) can be achieved with the hook of a #objectToSerialize where each class
can implement such message and not necessary answer self but something
different. In this case, the proxy can answer the target.
So....depending what is the best scenario for the materialization, I can
choose which of the options to do.
Thanks in advance,
--
Mariano
http://marianopeck.wordpress.com
Hi,
In the latest Pier, editing the CSS through the design command is no longer possible. It looks like the editor now displays the binary stream of the file instead of the text. Take a look in the attachment.
The Pier-Design package did not change, and I am not sure where I should look for this. Could anyone point me into the right direction?
Cheers,
Doru
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Hi,
I have a bit of trouble rendering a widget that aims to embed some other structures.
Here is the current code:
renderContentOn: html
html div
id: #cycler;
script: ((html jQuery: #cycler) cycle fx: 'fade'; timeout: self timeout; delay: self delay; speed: self speed; pager: '#cyclerNav') greaseString;
with: [
self sourceChildren do: [:each |
html div class: 'cyclerItem'; with: [html rendererInstance visit: each document] ] ].
It seems to work fine when sourceChildren contains only PRPages, but when there is a PRFile inside, it goes strange. For example, if I have three PRFiles in the collection, the rendering looks like:
<div id="cycler">
<div class="cyclerItem"></div>
<div class="cyclerItem"><img alt="One" src="/pier?_s=Zp6phh68i9hRHhnB"></div>
<div class="cyclerItem"><img alt="Two" src="/pier?_s=z2r2BcgQuxMPw_cc"></div>
</div>
<img alt="Three" src="/pier?_s=LFE6L8UkDNIyzAdN"></div>
What am I doing wrong?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
Hi,
I am trying the book component in the latest Pier and I notice that the user comments component does not seem to appear anymore. Is there something I should do, or is this a bug?
Cheers,
Doru
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Hi all,
It seems that I as pretty tired when I made my last changes in the image
in the processo to make it ready for a public site and I forgot the
admin password. There is any way to reset it from the image (instead of
the web interface)?
Thanks,
Offray
Hi all,
It has been really nice my re-encounter with Smalltalk using Pharo,
Seaside and Pier, and knowing that there are some important projects to
learn like Moose or Aida and Illiad. I want to make my site using Pier,
and "consolidate" my on-line presence there. Previously I have used Moin
Moin and Tiddlywiki and now I'm writing my thesis using
reStructuredText, so would be nice to have a single markup language for
all this writing and I think that this one should be reST. So the
project is giving Pier the possibility to use this as a Markup language.
I have seen that there are some projects like Helvetia and Pettit Parser
that, perhaps, may be used in this kind of project, but I really don't
know if this is feasible or where to start. So if anyone have some ideas
on this I would really like to hear them.
Thanks,
Offray
Hi,
Citezen-Pier does not seem to work anymore. The first thing I noticed is that it still relies on Rio for accessing the bib file. I guess we should update it to work with Filesystem.
Anyone happens to have an interest to work on it?
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
Hi,
I'm experimenting with a JSON converter for objects with Magritte
descriptions. So far I've added the following to GRObject:
jsonOn: aStream
| description |
description := self description.
description children isEmpty ifFalse: [
| first |
first := true.
aStream nextPut: ${.
description do: [ :each |
first
ifTrue: [ first := false ]
ifFalse: [ aStream nextPut: $, ].
aStream
json: each label;
nextPut: $:;
json: (each accessor read: self) ].
aStream nextPut: $} ]
you can then generate JSON from an object, for example:
((PRPage named: 'examplePage') contents: '!!Hello', String crlf, 'Hello
""world"" check') asJson
gives:
'{"Name":"examplePage","Visibility":false,"Navigation
Title":"ExamplePage","Tags":[],"Title":"ExamplePage","Owner":null,"Group":null,"Contents":{},"Plain
Text":"Hello\rHello world check","Environment":null,"Style
Sheet":null,"Shortcut Icon":null,"CSS Classes":null}'
The method fails with recursive structures, but otherwise is appears to work
well.
Does this look like a sensible approach? Has anyone else implemented
anything similar?
Thanks
Nick