Tags:
create new tag
, view all tags
The idea of reimplementing TWiki in Php.

Personally I think this would be a lot of work, and would directly compete with other products such as PhpWiki.

I personally think a better idea is to componentise the RenderingPipeline so that it is embeddable in other products, linking the two with a WebServices bridge.

If we kept the Perl interpreter around it need not be inefficient.

-- MartinCleaver - 14 Jan 2003

I think there's two distinct points here, so I'll address them as such.

Firstly, I mentioned TWikiOnPhp in the PhpWiki topic, as I think it would be useful for my installation, and I wondered what others thought. This can be thrashed out here, but the main requirement I had in mind was that I now have an installation of TWiki, with all the data, and a team of developers who know PHP.

I'd like to be able to create a PHP version, which can use all the existing data, and work as if there's no difference, but would then allow further changes in PHP. It doesn't necessarily have to work the same way underneath - just provide the 'correct' view of the data.

I'm not sure I really clarified that... hmmm...

As for the WebServices idea, it's definitely a good one assuming speed is good. If it used a RESTful approach, it should blend in nicely with the existing HTTP architecture. Would I be correct in thinking that the Render Pipeline includes all plugins as well ?? Having a plugin architecture based on WebServices would be excellent, if implemented correctly.

-- MichaelKearns - 14 Jan 2003

You are basically saying that you would rewrite TWiki in Php. If you do that, you might as well use PhpWiki as you would lose all the benefits of the TWiki community.

The separable RenderingPipeline idea does include all the plugins, yes. Initially that is pretty much all it would include, with the possible exception being the inclusion of TWikiStore's RcsLite module. Even that though, if the TWiki were properly componentised, should be optional; TWiki should be able to store its data in a database or in CVS. A far goal is to rearchitect TWiki as described in CodevDocumentationProject.

If you didn't want to lose the plugins benefits offered by the TWiki Community you would have to build a bridge to TWikiPlugins. This would inevitably be Php->Perl. If you are going to do that you might as well take on the job of separating out the RenderingPipeline. Certainly I cannot do it as I am about to be full-time occupied (with a Masters of Business at Melbourne Business School); indeed I expect my participation on TWikiDotOrg to drop significantly in the next year and a half.

I would be happy to review though, providing I can fit it in my schedule.

-- MartinCleaver - 14 Jan 2003

I don't want to rewrite it - I want, I suppose, to write a compatible wiki that can work with the existing data. I guess that's not really appropriate here.

I like the idea of the modular system, but I'm also not the person to do it, being exceedingly full-time employed as a Java Technical Consultant. The few spare moments I have at home are currently being ploughed into Python anyway ;o)

I think I'll regather my thoughts on what exactly I'm trying to achieve, but I don't think that a basic implementation in PHP would be that hard.

-- MichaelKearns - 15 Jan 2003

In hopes of helping you regather your thoughts:

  • There are wikis written in PHP (there are a lot of wikis out there -- see some of the pages (outdated now, and never complete and fully correct anyway) in or linked from the WikiEngineReview). Or these (some of the pages linked from there):
    • ChoosingaWiki
    • WikiEngines -- which lists wiki engines by language of implementation (although I think it still includes some wiki sites as opposed to wiki engines)

  • Almost every wiki uses a different markup language.

  • When I looked, TWiki seemed to be the most featureful and strongly supported wiki (with a core group of developers)

What's my point? Well, I wasn't going to state one, but I guess I think, much as I dislike Perl, if you like the TWiki features but want to enhance it (a little or a lot) you might as well learn Perl or find some other way to contribute to TWiki development (money, documentation, testing, participating on Codev to help define features although that's a mixed bag, as with every open source project, there's no guarantee anyone will see fit to implement what you define).

-- RandyKramer - 15 Jan 2003

Well, I chose TWiki for the very same reasons - For me it was just unfortunate that it's written in Perl. As I use Java and PHP extensively every day for work, and am learning Python at home, I don't really have the brainpower to take in Perl as well (Although I appreciate it's not too different).

I've decided against my rewrite for the moment, but I would be ecstatic if anyone can tell me how to achieve the following:

How would I alter the render pipeline so that just before the view data is passed back to the browser, it gets passed into mod_php ?

This would allow me to embed PHP into my text, and have it processed after TWiki has finished. The amount of flexibility this would give would be superb, possibly a security risk for many public sites, but on my work intranet it wouldn't be a problem.

Any thoughts ? Anybody ??

-- MichaelKearns - 15 Jan 2003

There was some discussion of this in ConditionalRendering - might be possible through some PHP trickery, i.e. PHP pages calling TWiki CGI scripts perhaps, even without a separate rendering pipeline.

-- RichardDonkin - 16 Jan 2003

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2004-10-19 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.