Keeping the data as property of the page would break the performance of the
plugin.
(and would make a sliding behaviour like dividing all counts by 2 every time
period
that much more difficult to implement)
Originally I opted against putting the data in a generated wiki page because it
will
get in the way of people. An attachment to a special page like PopularPages
also
did not seem the way to go - replacement bypassing the versioning of pages and
attachments
breaks the general behaviour.
With regard to context; one would expect a count per space if spaces are
separate
wikis.
regards, Andre
-----Original Message-----
From: Janne Jalkanen [mailto:[email protected]]
Sent: zondag 30 augustus 2009 22:41
To: [email protected]
Subject: Re: PageViewPlugin
The first determination would be to decide whether this data should be
stored as a Property of a WikiPage or as a generic binary blob under
some special page...
Easiest would be to simply define a special page and then store it as
a Binary blob there. This would mirror the current storage in workDir.
JSPWiki stores currently the WikiPages as JCR Node /pages/<space name>/
<wikiname>. We could store the data under /wiki:PageViewPlugin/,
perhaps? But that means that you need to access the JCR store directly
(using the JSR-170 API), and it might not be import/exportable. THe
other possibility is to define a /pages/<space name>/
System:PageViewPlugin or something and store it there, but then it
becomes tied to a particular wikispace (=something else than a static
var is needed to store the data).
Opinions?
/Janne
On 30 Aug 2009, at 20:29, Florian Holeczek wrote:
> Hallo Harry,
>
> conceptually, this is metadata of the related page. In JCR speak, it's
> a property of the page node.
>
> regards
> Florian
>
> Ursprüngliche Nachricht vom 30.08.2009 um 19:24:
>> Yes,
>> do you have a few more details on how to implement, should it be
>> stored in a
>> special page, or something else.
>> Maybe some skeleton or sample code could give a jump start.
>
>> regards,
>> Harry
>
>> 2009/8/30 Janne Jalkanen <[email protected]>
>
>>>
>>> For 3.0, it might be nice to store the contents in the repository as
>>> opposed to the work directory. That way you don't lose it
>>> accidentally if
>>> you empty the workdir or move the machine or something. Workdir is
>>> supposed
>>> to be a place for things which can be recovered...
>>>
>>> /Janne
>>>
>>>
>>> On 30 Aug 2009, at 13:11, Harry Metske wrote:
>>>
>>> The Plugin is in the core now for 2.8.
>>>> I'm working on the 3.0 version, but it requires some more
>>>> adjustments
>>>> (like
>>>> replace oro regexp with Java 5 regexp).
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/8/26 Harry Metske <[email protected]>
>>>>
>>>> Hi,
>>>>> Andre has sent a signed ICLA to ASF's secretary.
>>>>> So I'd like to add this plugin to the core.
>>>>> I will add some testcases and hope to commit it somewhere next
>>>>> week if
>>>>> there aren't any objections.
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2009/8/12 Harry Metske <[email protected]>
>>>>>
>>>>> I sent Andre a direct email, and got an out-of-office reply, we
>>>>> should
>>>>> wait
>>>>>
>>>>>> a couple of weeks still.
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>>
>>>>>> 2009/8/9 Janne Jalkanen <[email protected]>
>>>>>>
>>>>>>
>>>>>>> An improvement would be that it could also listen to the
>>>>>>> WikiEngineEvent.SHUTDOWN to be on the safe side.
>>>>>>>
>>>>>>> Is Andre on this list? Would you mind contributing your code
>>>>>>> to us?
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>>
>>>>>>> On 9 Aug 2009, at 11:59, Harry Metske wrote:
>>>>>>>
>>>>>>> the plugin spawns a separate thread when it first initializes
>>>>>>> (using a
>>>>>>>
>>>>>>>> static var).The thread saves the in-memory counts to a file
>>>>>>>> each 5
>>>>>>>> minutes.
>>>>>>>>
>>>>>>>> Harry
>>>>>>>>
>>>>>>>> 2009/8/9 Florian Holeczek <[email protected]>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't believe either it would be too late to integrate in
>>>>>>>>> 2.8,
>>>>>>>>> since
>>>>>>>>>
>>>>>>>>>> it would be just a new plugin and does not change existing
>>>>>>>>>> APIs in
>>>>>>>>>> any
>>>>>>>>>> way.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ok, fine then! :-) Was thinking of the policy to only
>>>>>>>>> integrate
>>>>>>>>> bugfix
>>>>>>>>> code into a stable branch, but indeed, it's a non-invasive
>>>>>>>>> change.
>>>>>>>>>
>>>>>>>>> (Note, however, that there's still a good reason to store
>>>>>>>>> page view
>>>>>>>>>
>>>>>>>>>> counts in a separate file: performance. Having a database
>>>>>>>>>> write
>>>>>>>>>> (possibly several) for each read would be very heavy.
>>>>>>>>>> Better to
>>>>>>>>>> journal it and keep a latest count in memory; then upon
>>>>>>>>>> startup read
>>>>>>>>>> the journal back in. JCR does not have the concept of
>>>>>>>>>> appending to
>>>>>>>>>> a
>>>>>>>>>> Property either.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> AFAIK this is just the way Andre has implemented it :-)
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> Florian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
