Ok, let me see... this is really simple when you understand it, basically to make a portlet you need 2 things (i.e. lars-blogger / weblogger):
1. Applet: dotlrn-weblogger (overhead to register to the portal system)
2. Portlet: weblogger-portlet (contains the templates that render the content inside de portlet)
Both, in /tcl/apm-callback-procs.tcl define a set of standard SC (service-contracts) to register in the portal system.
Then, the process to do a portlet is relatively simple since the most part of the code is quite similar, this is an example:
1. cp dotlrn-weblogger dotlrn-your-pkg; cp weblogger-portlet your-pkg-portlet
2. in both dirs change EVERYTHING that says weblogger (the name of the files and inside them as well) to your-pkg. (with emacs use M-% to replace all at once)
3. to define what you gonna show inside the portlet you have 2 files in your-pkg-portlet/www:
3.1 what the user gonna see: your-pkg-portlet.* (quite similar to the pkg index page)
3.2 what the admin see: your-pkg-admin-portlet.* (usually a set of links to /admin of you pkg)
4. Both files has lines of code that are almost standard among all the portlets, for the user portlet, it verify if it's being called from a community/class or from the user portal, and in this way aggregate data from the proper place(s). For admin is easier, since it just works for communities/class. Also there is logic for the shaded stuff, etc. (means, when you minimize a portlet). Then, these pieces of code are standard and you can just copy them, then you just add your code from the index page.
5. In the user portlet you'll get a package-list.
6. I think the easiest way to deal with this is to have a look in the code and start to build your own portlet.
7. the example of weblogger is the correct one, since uses a tcl-spec instead of hardcoding directly the calls to an specific DB, which means, if your portlet works in PG is most likely to work on oracle as well.
Hope this make the things clear!.
