Do you think it is ready to be uploaded to SF.net? That's usually the
best way to find testers... :)
On 1 Jul 2004, at 12:05, Nick Gerakines wrote:
> Ok, its done. If anyone is need of something to do please take a
> look at it. I need people to test it and see if they are able to work
> around the invitations to see blogs that are sapposed to be dubbed
> hidden. I have it up and working on my site and i've tested it as much
> as i can think to right now. Just untar to main dir, and add the
> pluging class to the plugins dir. An example of an invitation would
> Don't flame me for shamelessly ripping off parts of the karma plugin
> to get a feel for how to do it. The attached files are not a final
> version, i'll do some cleaning and add comments and then some
> admin-friendly stuff. Thinking about adding a feature to optionally
> email the invitation to someone apon creation. Also a batch invitation
> for generating a list of 30 one time use invitations. Another thing is
> to set an option to have the invitation delete itself when it hits 0
> views left. Another note, to keep it simple it just counts down on
> views left so setting an invitation to -x gives infinate views. Also
> have it logging ip/now() when viewed.
> ~ Nick
> Oscar Renalias wrote:
>> A different question, still vaguely on topic...
>>> When should plugins begin to be coded for version 1 (wiki entry
>>> titled "Plugins in 1.0")? I've read the basic outline on the wiki
>>> and I'm excited about the event handler. However, there doesn't
>>> seem to be much else written to completion (click the link for event
>>> messages, for example). What commands may be referenced from the
>>> PluginBase class? The example shows several references to
>>> methods/attributes that are not listed in the PluginBase page on the
>>> wiki. Guess it's not all ready for release? But back to my
>>> question, when should developers begin working on plugins for 1.0,
>>> and how much difficulty do you think would it be to port current
>>> plugins over to the new api?
>> Of course some changes will be needed for plugins if we want them to
>> make the
>> best of the new plugin framework. But I hope not too many :)
>> If the only thing the plugin does is export some kind of object or
>> to the template, then no changes are needed.
>> For plugins that had some kind of interaction via the admin interface
>> with the
>> user (using the current "configure" link), then it would be better to
>> port them.
>> It will mean a little bit of extra work for the author but I think
>> the benefits
>> are clear: possibility to use templates, possibility to localize
>> them, etc.
>> I can offer all my help to plugin authors if needed :) I'll also try
>> to finalize
>> the docs in the wiki and basically, plugin authors can start using
>> the new
>> framework anytime. It will also help me (or in general, the persons
>> the core classes) to see if there is any bug or problem in the
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
>> self defense, top technical experts, no vendor pitches, unmatched
>> networking opportunities. Visit http://www.blackhat.com
>> pLog-General mailing list