Include .800 library in .764? :: Zikula Community

Get Zikula 1.3.3!New core, modules & more

Quick Links

Donate Today!Support your Software

Documentationlearn, share & develop

Watch

GitHub Core

Show your support for Zikula! Sign up at Github account and watch the Core project!

GitHub Modules

Forum Activity

internetking created topic »password problem« 25. May
mesteele101 responded to »ERR (3): E_USER_ERROR: Smarty error: [in pagesvar:pagesitem2en line XXX]…« 25. May
mazdev responded to »Pages 2.5.0 and updating - Page not found« 25. May
ehdwma created topic »Hide "Register new account" and change template to 3 col« 25. May
mesteele101 responded to »Zikula 1.3.3 - Selecting a category in Pages not working« 25. May
mdee created topic »How to implement returnpage ?« 25. May
nestormateo responded to »Fillters in Clip« 24. May

» Visit forum | » View latest posts

Zikula Blog

Anatomy of Open Source Projects on Mar 07
Continuous Review on Mar 01
Not Invented Here on Feb 24
How to Contribute Your Code at Github on Jan 13
10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
Submitting Bug Report Tickets That Get Results on Aug 17
Cozi Tricks #1: Syntax Highlighting on Aug 07

Include .800 library in .764?

Print topic

uheweb

Rank: Helper

Registered: Sep 16, 2004

Last visit: Oct 21, 2009

Posts: 731
Posted: Aug 02, 2007 - 06:51 AM

If one wanted to use .800 libraries in .764 (DButil, FormUtil, etc.) in a .764 environment, what would be the critical points that need to be modified?

I'm assuming:

1. include the folder \includes\pnobjlib
2. Add something to the .764 core to know where to find the libraries
3. Identify and modify/remove components that are dependent on other .800 features (ie, categories?, different calls to adodb? etc.)

Any direction from devs on what such a project would entail?

I know its not gonig to be as easy as dropping in the \includes\pnobjlib folder (wow, wouldn't that be great!) but any pointers are appreciated.

If I can get it working rather well, I'd be happy to offer the mods to anyone else too - with HUGE disclaimers.

I have several .800 modules in the works, but would like to backport to some .764 installs without rewriting all the code in a nearly deprecated format

Thanks!

NCM
UHEweb

edited by: uheweb, Aug 02, 2007 - 11:52 AM
AmmoDump

Rank: Team Member

Registered: Dec 07, 2003

Last visit: May 09, 2010

Posts: 2703
Posted: Aug 02, 2007 - 07:52 AM

Not sure, but did you check to see what openstar.postnuke.com includes in the base?

--
David Pahl
Zikula Support Team
larsneo

Rank: Software Foundation

Registered: Dec 31, 1969

Last visit: Oct 21, 2009

Posts: 3814
Posted: Aug 02, 2007 - 08:56 AM

Quote
If one wanted to use .800 libraries in .764 (DButil, FormUtil, etc.) in a .764 environment, what would be the critical points that need to be modified?

if you want to use .8 stuff you need to use .8 - there is no easy way (and no reason) to backport the key-features of the adam_baum release.

--
regards from germany
..::[Zikula Application Framework]::.. ..::[SEO-Blog]::.. ..::[CMS Sicherheit]::..
uheweb

Rank: Helper

Registered: Sep 16, 2004

Last visit: Oct 21, 2009

Posts: 731
Posted: Aug 02, 2007 - 12:20 PM

Openstar includes \includes\v4blib as well as modifying several core files. I've used this library on top of regular postnuke installs for nearly two years now.

Larseo, I realize there is no easy way. There is a reason, though:

Coding for .764 is painful now...
Coding for Openstar v4blib will soon be deprecated (tried several that worked previously on Openstar 4.04, and they do not even after converting all the Util calls as .800 uses some new methods such as the pntables defines, etc.) ...

Projects that are on hold "waiting" for .800 could be finished and ready for release, used on brave souls .764 installs if they want to try the mod, and be all the mroe ready for a .8 final

So, why not code for modules for .8 and have a .764 Openstar-like .800 compatible library?

Openstar did the same thing...just isn't caught up with .800 as of late.

My question then becomes... does the .8 flavor of the libs use too many other .8 features to have an Openstar-like lib package back to .764?

OR, would a .764 with the libs be able to run like normal, and if a module called a lib/class, only then load and use them?

I realize this is NOT a request that the Core team should be looking at...just wanted direction on if, in the devs minds, its possible and a rough estimate of the points of impact.

The other option is to build projects using RC code, and deal with the bugs there. Either way, its lots of work. Just trying to find the path of least resistance, yet have modules that are built to .8 standards.

NCM
UHEweb
Guite

Rank: Team Member

Registered: Jan 19, 2003

Last visit: Apr 06, 2010

Posts: 442
Posted: Aug 04, 2007 - 07:47 AM

uheweb

My question then becomes... does the .8 flavor of the libs use too many other .8 features to have an Openstar-like lib package back to .764?

As you know the .8 core represents a huge architectural improvement, therefore the changes relate certainly the whole system.

uheweb

just wanted direction on if, in the devs minds, its possible and a rough estimate of the points of impact.

It is possible to enhance .7 with the libs, but as the codebase is not based on a final release, it will contain risks for which you get no support in productive environments.

uheweb

The other option is to build projects using RC code, and deal with the bugs there. Either way, its lots of work. Just trying to find the path of least resistance, yet have modules that are built to .8 standards.

There are several modules using .8 technologies which you can refer to:

the system modules

the .8 example modules (svn versions)

Formicula 2.0 (svn version)

MultiHook 5.0 (svn version)

pn_bbsmile 2.0 (svn version)

pnUpper 1.0 and pnTopList 1.0 (svn versions)

...

edited by: Guite, Aug 04, 2007 - 07:48 PM

--
Guite | ModuleStudio
Landseer

Rank: Team Member

Registered: Jan 02, 2003

Last visit: Oct 21, 2009

Posts: 800
Posted: Aug 05, 2007 - 01:23 AM

Quote
does the .8 flavor of the libs use too many other .8 features to have an Openstar-like lib package back to .764?

Yes. If you want to use the .8 features, use .8. Even if!! (add as many ! as you want ) you would manage to make it working, consider the amount of work to support this hybrid monster.

Quote
The other option is to build projects using RC code, and deal with the bugs there. Either way, its lots of work. Just trying to find the path of least resistance, yet have modules that are built to .8 standards.

Axel already mentioned some modules that are .8-only, just have a look at them.

If you are not sure wether something is not working because of a bug in .8 or a misuse/misunderstanding of a new API function, we can clarify this here. Doing this at least helps to squish out some bugs that are hidden deep in the system.

--
"He is not dangerous, he just wants to play...."
uheweb

Rank: Helper

Registered: Sep 16, 2004

Last visit: Oct 21, 2009

Posts: 731
Posted: Aug 07, 2007 - 11:26 PM

Thanks for the input. I'll just write to .8, and write a custom script to convert to .764openstar for the sites that I don't want to babysit .8 RC's on

My biggest question was since Openstar does basically the same thing, doesn't seem it would be too hard to do the same with the 1 yr newer PNUtils versus the v4bUtils - but you're right, the upkeep would not be fun.

Rgash - going to have any more Openstar releases? Or just let .8 take over?

Thanks to all,

NCM
UHEweb
rgasch

Rank: Team Member

Registered: Jan 05, 2003

Last visit: May 28, 2010

Posts: 775
Posted: Aug 08, 2007 - 09:00 AM

Quote
going to have any more Openstar releases?

This is currently being debated. The original plan was to keep releasing an OS as an 0.8-based distro. However, with certain developments which have been going on within the coredev team, this may not be such a hot item anymore (basically, some people of the coredevs team are working on easy do-it-yourself distro build tools). More info on this after we discuss this at pnMeeting.

Greetings
R