Seaside - packaging instructions

[marten]

I think, that there should be a product oriented documentation telling the user how to package a Seaside application and how the framework is in general setup in a correct way during runtime (in a packaged image or ic based image).

Is there anything available ????????

[marten]

I think, that there should be a product oriented documentation telling the user how to package a Seaside application and how the framework is in general setup in a correct way during runtime (in a packaged image or ic based image).

Is there anything available ????????

When packaging Seaside apps all the #defined methods are mentioned - they belong to applications, which are not defined in the prerequisites. How should they be handled when packaging (using client packaging or server packaging) !?

[koschate]

When packaging Seaside apps all the #defined methods are mentioned - they belong to applications, which are not defined in the prerequisites. How should they be handled when packaging (using client packaging or server packaging) !?

Marten, you almost certainly want to package your Seaside app as a server, unless you've created some sort of monitoring user interface for it. That way, you can run it on a box without a graphical user interface.

If there are applications needed by Seaside that aren't properly pre-reqed by Seaside-related apps, I'd make those applications be prerequisites of whatever application is holding onto your launch code. You could also just force them to be included using packaging rules, but I don't care for that myself - should applications be removed down the road, you won't know until you actually try to package.

[marten]

If there are applications needed by Seaside that aren't properly pre-reqed by Seaside-related apps, I'd make those applications be prerequisites of whatever application is holding onto your launch code. You could also just force them to be included using packaging rules, but I don't care for that myself - should applications be removed down the road, you won't know until you actually try to package.

Yes, that's the way I've done for myself - and tell that additional application not to reduce itself. Actually Instantiations should change these "loaded" messages in all Seaside application - and make explicit calls (or fix the prerequisite of those Seaside application - there are more than 10 cases in 8.0.2). The "defined" message is general used to initialize all (application-) defined classes, having their own "initialize" message (.g. for registering).

I've found the same stuff in the Raphael libraries and removed them totally (will upload the changed library to vastgoodies) - because in that case they were not needed at all. I think, that a (not so good) programming style is introduced here ...

[marten]

I think, that there should be a product oriented documentation telling the user how to package a Seaside application

I've made progress ! A headless server is starting with my Seaside demo. In addition to the normal problems mentioned elsewhere in this forum I had additional several problem - I just said "do not reduce" to several Seaside applications just to make the system happy.

Well the server is starting, but my application does not work - not that I expect this. What is not working ? All resources (js libraries, css files) handled by subclasses of WAFileLibrary are not working (they work in the headfull image). Well at least I'm on my way to a headless Windows and later a headless Linux server.

[wembley]

The prereq of EmImageSupport is actually missing much lower down -- SstKernelExtensions. There is some (what I consider) bad coding practice there in that SstKernelExtension class>>#loaded and #removing methods have a direct reference to SubApplication's defined class instance variable -- this also occurs in other SST apps. This problem has been previously identified and will be corrected in V8.0.3. Case 47731.

[wembley]

OK, the lightbulb is now on in my head and I got it wrong the first time .

The reason that the defined class instance variable is referenced directly is exactly so as not to need the prereq. The reference is always in #loaded/#removing methods which should only be present in development images or ICs, never reduced-runtime images. EmImageSupport is in the Kernel IC, so all is good in an IC'ed runtime. If EmImageSupport was prereq'ed, at least some part of it would be brought into every reduced-runtime image (where it is not needed).

So, the right answer is to do exactly what the SST apps do, reference the defined class instance variable directly. Of course, it would be nice to have a comment somewhere (maybe in the #defined method) explaining this.

[marten]

The reason that the defined class instance variable is referenced directly is exactly so as not to need the prereq.

And what about the around 100 cases in all applications of Seaside, Javascript, Grease (all these "newer" apps) where "self defined" is used in these "loaded" and "removing" methods - instead of "defined" ? Then this kind of usage is wrong and should be changed .... ?

[wembley]

Marten -

In the big picture, it makes no difference. Since the #loaded and #removing methods should only be present in a development image or a packaged IC, and since kernel.ic includes EmImageSupport (where SubApplication class>>#defined is defined) and is a prerequisite ic to everything else in the system, there should be no runtime issues. Now, if for some reason some of your #loaded or #removing methods are getting included in a reduced runtime, then it is a different problem.

For V8.0.3, the VAPackageExporter in Pharo has been updated to take a different approach to load time initialization, so there are no longer any generated #loaded methods (although the generated #removing methods are still there).

[marten]

Marten - In the big picture, it makes no difference.

Yes, I understand - but the packager does not understand this big picture .... more or less interesting is, that the "error" messages do not come from the SST framework apps - but only from the apps where "self defined" is used. But ok, I see, that its wrong to have the loaded messages in the reduced image.

I think, that I will take the counter example and produce a reduced image - if the same problems exists even with these little examples, then I try the IC way to package the application just to get rid of these problems.

[wembley]

Marten -

I understand and that is why I have changed the VAPackageExporter to used defined rather than self defined.