[Isomorphic]

hi Claudio,

We've added type="text" to text-fields in the isc_userSkin DS so we deal with converting Oracle CLOBs - please retest with tomorrow's builds, dated August 27 or later, for that change.

The exportToFilesystem flag isn't directly supported in this case - but we agree that supporting it would be a good approach here. We'll look into it and update here when we have more information.

[claudiobosticco]

Thanks for the clarification.

For the userSettings field, for now, I'm having Maven add type="text".

May I ask if it would be feasible, with minimal effort, to make the custom export operation to also work with exportToFilesystem? I've tried to add it, together with export.allow.filesystem in server.properties, but it is ignored.

[Isomorphic]

Yes - the template folder contains files which allow the skin to continue to be edited in the Skin Editor. Differences in those files determines whether the skin is a "base" skin or not. A base-skin, of course, can be used as the basis for another custom skin.

[claudiobosticco]

actually it seems that adding type="text" to the userSettings field of isc_userSkin.ds.xml fixes the export problem.

Is it expected that the exported skin, without the "export as base skin" option ckecked, contains the "template" folder?

[claudiobosticco]

SNAPSHOT_v13.1d_2024-07-30/Enterprise Development Only

I can add that with the tweaks above I almost got it working, but when I try "export" I get this error:

java.lang.ClassCastException: class oracle.jdbc.driver.OracleClobReader cannot be cast to class java.lang.String (oracle.jdbc.driver.OracleClobReader is in unnamed module of loader java.net.URLClassLoader @2e005c4b; java.lang.String is in module java.base of loader 'bootstrap')

while "save" works.

Hello, any news about this issue?

[claudiobosticco]

If you mean "update" as in make further changes, without pulling in any changes in the base skin, then, the best approach is as outlined above: keep a spare SDK around, locked to a specific date, and update the skin there. Then, only changes you yourself have made will be applied, when you export it again.

Hello, I was actually referring to a scenario where I make additional changes AND incorporate any updates from the base skin, or even just re-export from a new version of the base skin, without making further changes myself, simply to integrate updates from the base skin into my custom skin.

I hope to find the time to put together a sample maven overlay to better illustrate what I have in mind

[Isomorphic]

Actually I'm interested in the opposite approach: I want to be able to update my custom skin at any time, whether in a week or a year, with minimal effort and without much thinking.

If you mean "update" as in make further changes, without pulling in any changes in the base skin, then, the best approach is as outlined above: keep a spare SDK around, locked to a specific date, and update the skin there. Then, only changes you yourself have made will be applied, when you export it again.

[claudiobosticco]

Yes, you would get base changes to the skin for any properties that had been changed, and that your custom skin did not override.

ok, thanks for confirming.

But the same thing would happen no matter what DB was used for storage.

If you're trying to remain on a fixed version of Shiva so you don't get unrelated changes, keep a copy of the SDK you exported from and don't update it. Simplest thing then is to use HSQLDB with that fixed-version SDK.

Actually I'm interested in the opposite approach: I want to be able to update my custom skin at any time, whether in a week or a year, with minimal effort and without much thinking.

[Isomorphic]

Yes, you would get base changes to the skin for any properties that had been changed, and that your custom skin did not override.

But the same thing would happen no matter what DB was used for storage.

If you're trying to remain on a fixed version of Shiva so you don't get unrelated changes, keep a copy of the SDK you exported from and don't update it. Simplest thing then is to use HSQLDB with that fixed-version SDK.

[claudiobosticco]

I'll try to explain the scenario which I have in mind.

Let's say that I used a past build to make a custom skin out of Shiva, using the SDK on my local machine, saved it on the HSQLDB and exported it.

Then some day I download the latest. Assuming that I kept a copy of past SDK, I could try to export data from that HSQLDB and import in the HSQLDB of the latest SDK. Or maybe it could just work to copy the hsqldb folder.

At this point I think I'll see all customizations I had done to my "custom Shiva", and if I export it, I'll get my skin *including* changes between the past and latest build, as new CSS styles for instance.
Am I right?

I hope this clears up why I'd like to save it on my DB (maybe on a dedicated schema), and be able to run the skin editor in a maven project, with my local tomcat.

The same maven project could be a maven overlay to include the custom skins (also versioned) in other applications, and be a local only webapp to run the skin editor.

At present only the error of post #8 is blocking me from doing this.

[Isomorphic]

It probably does make sense to keep a separate process (and DB) for modifying the skin vs including it in the live app. Note that you won't need the database for the live app - the exported skin is all you need.

Then it's just a question of, as mentioned above, being sure that you keep changes (called a "skin overlay") separate from the files that are produced by the export.

There doesn't appear to be a reason to move the skin data over to your live DB given this, but if you're having trouble with the export/import process for just data, then it's probably best to start a separate thread for that.

[claudiobosticco]

Hello, I'm still trying to imagine what would be the best setup to create, maintain and include in projects my custom skins.

I'm currently thinking of setting up a maven overlay, which could have a profile to deploy it on my private maven repo, including just my custom skins.

But it could also have a profile which deploys ,on my local tomcat, SmartClient with the skinEditor.

In this way I can start tomcat to create and modify skins, deploy them on the maven repo for inclusion in projects, and of course versioning them. It would also be easy to compare files to see if in the latest builds there are changes in the skins.

About your suggestion to use the included embedded DB: I think that later I could do isc_userSkin.exportData() to download a CSV to be imported in Oracle, right? Or it would require others steps?

As a side note, I've tried to export from the DataSources tab of the developer console (the "export" button for the single ds), in both the skinEditor and the showcase, and I get a 404:

[Isomorphic]

Unfortunately, we are probably not going to be able to get to this for a bit, as the lead developer in this area has had a laptop crash, when there were already other tasks queued up.

This error message likely indicates that the Skin Editor has not been tested well enough against Oracle, which appears to have idiosyncrasies in the JDBC driver that the framework doesn't automatically handle.

You should be able to continue to use the Skin Editor with the included embedded DB.

Just to ask - what's the use case here? Surely you aren't going to expose the Skin Editor to end users? It's not really set up for that.

[claudiobosticco]

SNAPSHOT_v13.1d_2024-07-30/Enterprise Development Only

I can add that with the tweaks above I almost got it working, but when I try "export" I get this error:

java.lang.ClassCastException: class oracle.jdbc.driver.OracleClobReader cannot be cast to class java.lang.String (oracle.jdbc.driver.OracleClobReader is in unnamed module of loader java.net.URLClassLoader @2e005c4b; java.lang.String is in module java.base of loader 'bootstrap')

while "save" works.

[claudiobosticco]

Hello, any news about this issue?