Loading...
 
Skip to main content

History: TikiPackager

Preview of version: 7

In the light of TikiInstallFeatureDev and maybe TikiCoreWishlist and TikiCorePrototype, it is probably easier for developers if something existed like a package creator.

Introduction


Suppose you are a tikiwiki developer and you have made a cool new feature/module/tiki-application (cfr Wiki/Articles/Blog/Tracker/...). How do you go about packaging all the necessary files, the necessary tables and settings?

Or even better: you have already created a package (or installed one) earlier and you want to release the changes you made to it to share them between you and the rest of the tikiwiki community.

In other words: how do you make those install-packages with script and maybe md5 hash as talked about in the 3 pages above?

General Idea


For installed features, it can display a list to what script you can do the upgrade. You can also set if you really want to deploy a 'final' versionm or if it is just a developers version (in which case the script is updated alone).

New features and installed features are handled the same in practically every way (except for a new script to be made).

Step 0

Select the feature you want to change the script from and also check if it is a local development script or not.

Also enter a description for the package as well as an optional 'licence' that would need to be accepted by the installer through the user before installation would occur. Licence may be proprietary and applies to all files contained in the package or specified by the licence limited to the files in that package only! (ie: you cannot relicence files that are not yours!)

Step 1

Dependencies! If your object depends on some other packages, select them here. By default the version
for requirement can be the one you installed or even versionless. You can change the one you need as well to be a larger/lower version number manually.

Step 2

Select the new files used out of a few different locations (img, lib, templates, ...) , with the ones in the script already omitted. You can also remove some files from the script in this step.


what about language.php?(sylvie)

It should get chopped up into smaller files anyhow (I read somewhere on tw.o a page by your hand). It would still need a default 'featureName_ISOName.php' maybe. A file release in a specific language (together with update packs for other languages) would then be a possibility (with the release requiring a certain featureversion to be preinstalled).

In any case, when you allow 3rd party modules to get developed, you cannot guarantee that all 3rd party apps/modules/plugins/features have the plethora of languages current tikiwiki has.

Of course there should be a minimal translation for common items in Tiki's core. (Things like Edit/Update, Add/Insert, Remove/Delete, Find/Search, Description, Date, ...) that does get loaded every request (maybe even cached in the session vars).

-- ( gongo )

Step 3

Move the files in the script to locations that suit more your idea for them to be installed into.

Step 4

Iterative step: select the affected database tables (either new ones, or the ones already contained in the original script, compared in version to the current meta-data in the database for that table).

Step 5

Select the object types associated with your App (from the values you as a developer would already have in your DB), which would also make the necessary retrievals of ARO, AXO and ACOs for that type.

Step 6 to x

Whatever comes along to being important when this idea gets tossed around ๐Ÿ˜‰

Examples

Example 1


Take for example myTikiApp. You have an admin page and application menu items, templates, a class, and some tables/settings.

Example 2


You have created a new filter that can be used as a pre-wiki filter. It consist of a class, and some object related entries in the specified tables (has no tables of its own).

Conclusion


This feature would allow us to make packages of features (or just image packs, or game packs or ...) that would enhance installation and get rid of the 'all-in-one' tiki installation.

It would also help us gain more momentum and would allow developers to submit/version their feature-releases for tiki in a more refined way.

Now, if only there were an api/core ๐Ÿ˜‰

As always


This is still throwing about some idea. Feel free to add a comment and/or add-to/modify this page.

See Also

  • TikiInstallFeatureDev
  • TikiCoreWishlist
  • TikiDesintegration
  • TikiCorePrototype
  • TikiPackageRemover

History

Advanced
Information Version
Marc Laporte 8
View
Smits Dimitri 7
View
Smits Dimitri 6
View
sylvie greverend 5
View
Smits Dimitri 4
View
Smits Dimitri 3
View
Smits Dimitri 2
View