Zikula Community

• **unknown user**
  
  

  • Rank: Softmore
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 111

  Posted: Jun 30, 2008 - 11:22 AM

  When looking at the modules shipped with Zikula 1.0 I noticed that they still all use the PN-prefixes in the directory structure and files. What is the reasoning behind this? I thought, when the PN Core Devs told everyone to quit using PN in the module name, they would also remove all the PN-prefixes from the core system files and functions to get the API clean of its PN-heritage before the official renaming.
  
  So what is going to happen now? Are there plans to switch the API to PN-prefix free code in the future (with backwards compatibility for some time) or is it going to stay like it is now indefinitely? And what are we going to tell new developers who will hopefully arrive at Zikula, what all the PN's stand for without mentioning the PostNuke name we are so eagerly (and rightfully so) trying to abandon?
  
  I might have suggested to push the Zikula renaming to PN.9 and use the PN.8 phase for all the renaming, but now that Zikula 1.0 is already out we should think about how to go forward from here.

  • 
  •  
• AmmoDump
  
  

  • Rank: Team Member
  • Registered: Dec 07, 2003
  • Last visit: May 09, 2010
  • Posts: 2703

  Posted: Jun 30, 2008 - 11:53 AM

  I don't believe we are trying to hide the fact that we were once PostNuke. The PN is being phased out. This is the transition. And yes, of course there will be backwards compatibility.
  
  There has been a lot of time wasted trying to figure these things out. Looking back I now realize the time I personally wasted trying to figure these things out. This is what the Steering Committee does. It has gone fairly smooth, so far. The good outweighs the not so good. I don't always agree with how things go or went, but at the end of the day, they have done a hell of job if you ask me.
  
  The PN should be coming out of the code. Pnrender is a little difficult, IIRC. But I believe this has already been started in the dev branch of the SVN.
  
  Just my 2¢
  
  
  
  --
  David Pahl
  Zikula Support Team

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Jun 30, 2008 - 04:01 PM

  As Dave has said there was always going to be a transitional period. If you take a look at the zikula 2 core you'll see that already most of the PN* APIs have been replaced.
  
  pnRender isn't difficult and has already been done. In this case a pnRender subclass exists for backwards compatability.
  
  Outside of the core that leaves the PN prefix on the folder names in modules and on the fields the database. The folder names are probably the hardest to deal with and retain backwards compatability since you'd have to introduce a full duplication of file system operations into the modules code potentially affecting performance. i.e. we need to look for pnadmin.php or admin.php etc.
  
  note what we said that the original poster is talking about is PN* in module *names* e.g. pnForum or pnCommerce. The reason for this was only partly the rebranding but also because it breaks the alpha pager in the modules list.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• **unknown user**
  
  

  • Rank: Softmore
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 111

  Posted: Jul 01, 2008 - 01:22 PM

  I'm happy to hear that I haven't been the first who thought of that issue and that it is already work in progress.
  
  To defend against performance regressions I would suggest to put the backwards compatibility into a deactivateable module, just like the legacy module before. Alternatively an easy to retrieve marker could be used to switch compatibility mode before accessing the rest of the module.
  
  Is there a rough estimate (version/date), when we will be able to begin writing modules without PN-prefixes in the code?

  • 
  •  
•  
•  

Users on-line

• michiel

This list is based on users active over the last 60 minutes.