Hi,
I'm using a PRTagCloudWidget and I've noticed that I'm seeing "div" appear as popular tag - which comes from the verbatim sections of my page's environment. I'd have thought that ideally verbatim sections shouldn't be included in tag cloud tokenisation???
Assuming I haven't missed some simple mechanism for extracting a pages contents without the verbatim section, I've been pondering how I'd implement it. I can see that by creating a visitor, say PRTagCloudTextWriter, and leaving the implementation of PRTagCloudTextWriter>>visitVerbatim: blank the resulting text will be free of any PRVerbatim objects. However I'm unsure how to wire it all together. Currently PRTagCloudWidget reads a page contents via PRCase class>>descriptionDocument which uses the PRCase>>document accessor, which give wiki text output. My initial implementation thoughts would be:
1) add a new accessor to PRCase say cloudText (as a PRTagCloudWidget extension) 2) PRCase>>cloudText would use PRTagCloudTextWriter to extract plain text without PRVerbatim content 3) PRTagCloudWidget, then needs a mechanism for tagging PRCase>>cloudText as the accessor it should use, in preference to PRCase class>>descriptionDocument. How about introducing PRCase class>>cloudTextdescriptionDocument (as a PRTagCloudWidget extension), which
PRTagCloudWidget would find and realise that it should be used in preference to PRCase class>>descriptionDocument?? Or perhaps I've missed something really simple??? Nick
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On 21 February 2010 15:26, Nick Ager <[hidden email]> wrote:
> Hi, > I'm using a PRTagCloudWidget and I've noticed that I'm seeing "div" appear > as popular tag - which comes from the verbatim sections of my page's > environment. I'd have thought that ideally verbatim sections shouldn't be > included in tag cloud tokenisation??? I think the PRTextWriter should probably not include the verbatim text. I'll remove it from there. Lukas > Assuming I haven't missed some simple mechanism for extracting a pages > contents without the verbatim section, I've been pondering how I'd > implement it. I can see that by creating a visitor, say > PRTagCloudTextWriter, and leaving the implementation > of PRTagCloudTextWriter>>visitVerbatim: blank the resulting text will be > free of any PRVerbatim objects. However I'm unsure how to wire it all > together. Currently PRTagCloudWidget reads a page contents via PRCase > class>>descriptionDocument which uses the PRCase>>document accessor, which > give wiki text output. My initial implementation thoughts would be: > 1) add a new accessor to PRCase say cloudText (as a PRTagCloudWidget > extension) > 2) PRCase>>cloudText would use PRTagCloudTextWriter to extract plain text > without PRVerbatim content > 3) PRTagCloudWidget, then needs a mechanism for tagging PRCase>>cloudText as > the accessor it should use, in preference to PRCase > class>>descriptionDocument. How about introducing PRCase > class>>cloudTextdescriptionDocument (as a PRTagCloudWidget extension), > which > PRTagCloudWidget would find and realise that it should be used in preference > to PRCase class>>descriptionDocument?? > Or perhaps I've missed something really simple??? > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Makes sense, though there's still the problem of how to make the PRTagCloudWidget have access to plain text rather than the current description which calls PRCase>>document - wiki text.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
It turns out to be simpler than I original thought:
1) PRCase already includes an accessor #plainText 2) I added PRCase class>>descriptionPlainText and set it to #readOnly and #beTagCloud 3) I removed PRCase class>>descriptionDocumentTextTagCloud: so that the wiki text from the document is no longer included in the tag cloud.
Pier-TagCloud and Pier-Model mcz files are attached. Nick
On 21 February 2010 14:44, Nick Ager <[hidden email]> wrote:
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki Pier-Model-NickAger.384.mcz (160K) Download Attachment Pier-TagCloud-NickAger.13.mcz (10K) Download Attachment |
In reply to this post by Nick
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
I don't think that PRSlideshow has been ported to Seaside 3 and Pier 2
yet. In Seaside 3 SUElement is called PTElement. Lukas On 23 February 2010 13:29, Reza RAZAVI <[hidden email]> wrote: > 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 > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> *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. I've never used Pier-Slideshow-MMP.13, I think it is broken and should maybe removed form the repository? I use Pier-Slideshow-lr.12. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Nick
I've integrated the changes a while ago.
Lukas On 22 February 2010 01:39, Nick Ager <[hidden email]> wrote: > It turns out to be simpler than I original thought: > 1) PRCase already includes an accessor #plainText > 2) I added PRCase class>>descriptionPlainText and set it to #readOnly and > #beTagCloud > 3) I removed PRCase class>>descriptionDocumentTextTagCloud: so that the wiki > text from the document is no longer included in the tag cloud. > Pier-TagCloud and Pier-Model mcz files are attached. > Nick > > On 21 February 2010 14:44, Nick Ager <[hidden email]> wrote: >>> >>> I think the PRTextWriter should probably not include the verbatim >>> text. I'll remove it from there. >>> >> >> Makes sense, though there's still the problem of how to make the >> PRTagCloudWidget have access to plain text rather than the current >> description which calls PRCase>>document - wiki text. >> > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
I've integrated the changes a while ago. Thanks Lukas. I noticed that you'd fixed the coupling I unintentionally introduced between Pier and the TagCloud. Hopefully one day I'll submit a patch which doesn't itself require patching...
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
>> I've integrated the changes a while ago.
> > Thanks Lukas. I noticed that you'd fixed the coupling I unintentionally > introduced between Pier and the TagCloud. Hopefully one day I'll submit a > patch which doesn't itself require patching... That's no problem. Please just commit your changes to the main repository. Your code is generally of very high quality. I suggest we create a new public repository called 'pieraddons2' where we can collect all the different plugins and extensions, and that we make the main repository read-only. I've already added the top 99% committers (Julian, Dale, Nick, Doru and me) as developers. If anybody else would like to commit directly to the Magritte and Pier repositories, please ask in the list. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
At 13:36 26/02/2010, Lukas Renggli wrote:
>I suggest we create a new public repository called 'pieraddons2' where >we can collect all the different plugins and extensions, and that we >make the main repository read-only. Good idea! >If anybody >else would like to commit directly to the Magritte and Pier >repositories, please ask in the list. I'm using Pier as a core component in a major project. I may consequently have some patches to propose here and there. However, at least at this point, I don't feel that it will need to commit directly to the main repository. The integration, when found useful, could be done by one of the main developers, after having discussed the proposition through the list. Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |