At 08:59 26/02/2010, you wrote:
>Maybe using FileDirectory wasn't such a good idea in the first place.
>Maybe we should change it to a string to do a relative/absolute lookup
>from the image directory? Or, oh well, we could use the Filesystem
>framework
Thank you for your prompt response!
The current implementation works just fine. It looks like that we
just need to separate the *default base directory*, from another
*application-specific base directory*. I'd *simply* do the followings:
- Add MAExternalFileModel to the Smalltalk start-up list to ensure
that the default value gets automatically updated.
- Add an alternative class instance variable, for those applications
that would need to reference a specific directory (without automated update).
Does this make sense?
Otherwise, the issue appeared since I'm used to copy my image from a
*dev* directory to a *prod* directory, before executing my
distribution generation script (sort of "PRDistribution new
register"). I addressed the issue by simply adding to that script
*MAExternalFileModel initialize*.
Regards,
Reza
Hi,
MAExternalFileModel does not belong to the Smalltalk start-up list,
and the cached *baseDirectory* value is not updated by program.
Consequently, when a Pier image is moved from directory A to B,
PRFiles keep referencing 'A/files' instead of 'B/files'.
Has this been designed this way by purpose?
Regards,
Reza
Hi Lukas,
If I type the following in a page:
{{{""This is a bold text""}}}
I get the following after interpretation:
""This is a bold text""
Which is what I was expecting.
But, if I type the same text in a table cell as follows:
||{{{""This is a bold text""}}}|
I get the following in a table:
This is a bold text}}}
Which I wasn't expecting.
May I ask you please what I'm missing there?
Thank you in advance for your response,
Reza
Hi,
I have a container component that renders a series of subcomponents. The
number of subcomponents is based on the number children within my structure.
My initial implementation cached the components and returned the cache
within #children and iterated over the cache within #renderContentOn:.
A problem arises when I add a new child to my structure. The container
component needs to invalidate it's cache when the structure changes or once
I rendering cycle completes. I tried hooking into #initialRequest: but that
didn't seem to be called each time I visited the page. I guess I could use
Announcements but wonder if there is a simpler solution? Thanks in advance
Nick
At 17:23 23/02/2010, Lukas Renggli wrote:
>I've never used Pier-Slideshow-MMP.13, I think it is broken and should
>maybe removed form the repository?
Well, sooner or later people will need a Slideshow component for
Pier2. Since *Pier-Slideshow-lr.12* is working in Pier2 almost as it
is, I'd vote to use it as a basis for the port to Pier2, except if
somebody decides to take the responsibility to port *Pier-Slideshow-MMP.13*.
I actually had a look at *Pier-Slideshow-MMP.13*, and am not
convinced that its design is 100% percent consistent with that of
*Pier-Slideshow-lr.12*. But, there are interesting ideas that could
be integrated into *Pier-Slideshow-lr.12*. I've started some work in
this direction, but unfortunately won't have time now to finish it.
If somebody is interested in having a look at it and eventually
finish the integration and port work, please tell me to send you my package.
Regards,
Reza
At 14:13 23/02/2010, you wrote:
>I don't think that PRSlideshow has been ported to Seaside 3 and Pier 2
>yet.
This is actually why I'm having a look at it.
*Pier-Slideshow-lr.12* seems working just fine, but now I won't have
time to test the animation.
As for *Pier-Slideshow-MMP.13*, it seems more tricky since looks like
there are references to absent methods (e.g. #descriptionLooping &
#descriptionWidth). I couldn't explain that. Maybe I'm missing something.
>In Seaside 3 SUElement is called PTElement.
Thanks Lukas! If the *Pier-Slideshow-lr.12* that I've in my current
Pier 2 image, and have a little bit hacked, seems you useful as a
basis for a full port to Pier 2, please let me know to upload it to
your repository (Pier 2).
Cheers,
Reza
Hi.
I'm getting an error, "Command Classes: Invalid input given", after
adding a command to a PRCommandsWidget and clicking save.
Here's the simplest way that I can reproduce it:
Starting with the Pier-1.2 app image downloaded from piercms.com, log in
as admin, browse to environment >> commands >> widget, click edit. Move
the 'add' command over to the left hand list. Save the component. Edit
it again, move the 'add' command back to the right hand list, and click
save.
Thanks,
Nick Brown
Hi Lukas,
What would be the best solution to get ride of those references to to
SUElement in #updateAnimateOn: ?
Based-on the comments in *Scriptaculous-Core-lr.86*, I'd expect to
find SUElement in *Scriptaculous-Core*. But this is not the case.
Thank you in advance,
Regards,
Reza
At the moment I'm doing a fun web project. The complete thing tries to go as close with pier as possible. When it comes to testing I used seaside testing so far. I'm interested what you guys are using mainly for testing your applications (seaside or pier). Is there any special kind of testing if it is about pier widgets and the like?
I can imagine that using albatross it doesn't matter if it is plain seaside or pier. But probably there are neat things I don't even know off.
thanks in advance,
Norbert
At 11:44 21/02/2010, Lukas Renggli wrote:
>Mixing HTML with wiki is
>problematic, because it destroys the independence of the output
>format.
[...]
>To get bold text you should use the markup ""some text"", not the HTML tags.
Sure, but in that case I wouldn't have encountered that issue, and
consequently learnt the above interesting point -:)
>I'll fix that.
Already integrated, and tested; many thanks again!
BTW, may I ask you considering the integration of the following minor
change into your code base:
PRListWidget >> renderContentOn: html
| items |
items := self items.
items isEmpty
ifFalse: [ self renderItems: "self" items on: html ]
It just avoids computing twice the items list, and would allow me
removing this from my patch list.
Regards,
Reza
