]project-open[ My First Package

  • 932 views
Uploaded on

This tutorial guides you through the process of creating a new package in ]project-open[ and explains how to distribute the new package.

This tutorial guides you through the process of creating a new package in ]project-open[ and explains how to distribute the new package.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
932
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
57
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. My First Package The ]project-open[ Data-Model , Frank Bergmann, 2010-10-05 Creating a “Hello World” package in ]project-open[.
  • 2. Creating a New “foo-bar” Package
    • We will use the „Package Manager“ to create a new package:
    • ]po[ Home -> Admin -> OpenACS Package Manager
    • The Package Manager shows the list of currently installed packages.
    • -> Create a new package (at the end of the page)
    • Example Package:
      • We will use „Foo“ as our „organization“ name. „Foo“ stands for „First Object Organization“
      • We will use „bar“ as the package name. „Bar“ stands for „Business Application Resources“.
  • 3. Creating a New “foo-bar” Package
    • Package Key „foo-bar“: Organization name – Package name for customer packages. OpenACS “kernel” packages are prefixed with “acs-*”. ]project-open[ packages are prefixed with “intranet-*”.
    • Package Name „First Object Organization – Business Application Resources“
    • Package Plural Same as Package Name
    • Package Type Please always choose „Application“ if your package includes TCL/ADP pages
    • OpenACS Core? No (unchecked):
    • Singleton Yes (checked): All ]po[ are singleton. This means that you can only install one instance of the package in the system
    • Auto-mount URI „foo-bar“: Same as Package Key by default. This URI determines where the new package will be „mounted“ (i.e. http://localhost/foo-bar/)
    • Package URL „http://foo.com/repository/apm/packages/foo-bar“ This is the place where users could download new versions of the package in the future. Not relevant currently, except if you want the OpenACS community to include your package in their distribution
    • Initial Version „0.1d“: Please enter a version string. Normally, versions should look like „1.2.3“. A final „d“ indicates a developer version.
    • Version URL „http://foo.com/repository/apm/packages/foo-bar-0-1d.apm“ (automatically created by the Package Manager)
    • Summary „Provides important application resources for businesses“ A one paragraph description for users who have never before heard about your package
    • Description More extended description
    • Primary Owner “Peter Pan”
    • Primery Ownwer URL “mailto:ppan@milkyway.com”
    • Secondary Owner “”
    • Secondary Owner URL “”
    • Vendor “First Object Organization”
    • Vendor URL http://www.foo.com/
    • Please note that you won’t be able to change Package Key and Auto-Mount URI after creating the package.
    • You can change all other values during development, so don’t worry too much about them now.
  • 4. “ foo-bar” Post-Creation Actions
    • You will need to “mount” the package after creation (OpenACS doesn’t mount the package during package creation…)
      • Package Manager => foo-bar => “Uninstall this package from your System” => (no restart necessary)
      • Package Manager => Install Packages => Check “foo-bar” => Next => Restart Server
    • Please check your /packages/ folder. OpenACS has created a default folder structure for the new package:
      • /packages/foo-bar/ Main folder for the package
      • /packages/foo-bar/sql/
      • /packages/foo-bar/sql/postgresql/ PostgreSQL specific creation and drop scripts
      • /packages/foo-bar/sql/oracle/ Oracle specific data-model, not used in ]po[ at the moment
      • /packages/foo-bar/tcl/ TCL Libraries for the package
      • /packages/foo-bar/tcl/test/ Not used in ]po[ usually
      • /packages/foo-bar/www/ Place your TCL/ADP pages here!
      • /packages/foo-bar /www/doc/ HTML package documentation
    • Create a test page
      • Please use your favorite editor and create a file /packages/foo-bar/www/index.adp with the contents: “<h1>Hello World</h1>”
      • Now enter the URL: http://localhost/foo-bar/index. You should see “Hello World”.
      • In case of issues please consult the error.log file in /log/error.log
    • Congratulations, your first page of your first package is working!
  • 5. Distributing Your foo-bar Package
    • To distribute your package it is sufficient to “zip” or “tar” the /packages/foo-bar content:
      • cd ~/packages/
      • tar czf foo-bar.0-1d.tgz foo-bar (please observe the standard for naming packages .tgz files).
    • Windows users: Please make sure your package files use Linux style line breaks. In editors like “TextPad” you can choose between Windows line breaks (CR-LF) and Linux (LF only).
  • 6. Publishing Your foo-bar Package
    • We (the ]po[ core team) can publish your
    • package on the www.project-open.org if you want:
    • Please contact [email_address] for a user account on www.project-open.org with edit permissions on the Wiki.
    • We will create two new Wiki pages for you:
      • package_foo_bar: A page for your new package.
      • partner_foo: A page to present your organization
    • Please include specific information on your package_foo_bar page about the purpose of the package, the target sector (ITSM, Translation, ALM, …), license, preconditions etc.
    • Please clearly state the development status/maturity of your package and if the package DOES NOT support one of the “packge services” listed on the next page.
  • 7. Package “Services” Overview
    • ]project-open[ packages need to “live together” with other packages in a customer’s server.
    • There are certain expectations of ]po[ users on how a package should integrate with other packages. These “expectations” can be summarized as a number of “services” that a package should use in order to provide a look-and-feel like other packages:
      • Pages – You may want to show the user information about business objects and/or allow the user to take actions.
      • Templates and the ]po[ design – Integrate your package seamlessly into ]po[
      • Portlet Component – You may whish to show information from your package in other pages, such as the ProjectViewPage (/intranet/projects/view) etc.
      • Business Objects and Data-Model – You will probably need to create database tables in order to store information of your package.
      • Libraries – Libraries consist of procedures and functions to be used by pages or by other packages.
      • Menu Tab – You may want to create a new Tab in the menu bar so that users can get to your package.
      • Permissions – You may want to restrict access to your business objects
      • Localization – Allow users to translate your package into different languages
      • Categories – Categories represent the value of drop-down boxes. You may want to use ]po[ categories to define status, type and other information about business objects in your package, so that Application Administrators can configure your package using the standard ]po[ administration screens
      • Parameters – You may want to allow an Application Admin to modify behavior of your business logic. Generally, parameters allow you to eliminate hard-coding values in your package code.
      • New & Edit Pages – Allow the user to create and modify business objects. (=> Form Builder)
      • View Pages – Allow the user to see the contents of a business object (=> Portlet Layout)
      • List Pages – Allow the user to see lists of business objects (=> List Builder)
      • Reports – Allow the user to extract lengthy reports about your business objects
      • Full-Text Search Engine – You may want to let users search for contents in your package
      • Automatic developer documentation
      • Mail – Send and receive emails
      • Notifications – Allow your users to fine-tune the amount email notifications they are interested in
      • Calendar – Provide your users with a calendar view to their business objects
      • Dynamic Fields – Allow Application Admins to extend your business objects with dynamic fields
      • DynViews – Allow App Admins to modify the columns displayed by ListPages
      • Web-Services – Exchange information with external applications
      • Workflow – You may want to start workflows when creating new objects in your package
      • Finance – Create financial items that represent the economic impact of actions represented by business objects
  • 8. Frank Bergmann [email_address] www.project-open.com