skinEditor deployment

[claudiobosticco]

Hello, with the latest 13.1 I'm trying to deploy (in my local environment) the skinEditor, but when doing fetches on isc_userSkin it raises this error:

Transport error - HTTP code: 404 for URL: /JcaAuth/tools/skinTools/skinEditorOperations

any idea of what am I missing?

[Isomorphic]

In order to use the Skin Editor in your actual deployed app, you need to deploy at least some of the Tools module:

https://smartclient.com/smartclient-...oolsDeployment

Basically, the Skin Editor is not safe to expose to just any normal user. So we added special endpoints that allow the operations required by the Skin Editor, and placed them in a special directory so you can password-protect that area.

[claudiobosticco]

Hello, actually it seems that I've deployed all directories that are also present in the SDK:



But this is what I see regarding the fetch which fails:



the fetch URL isn't the usual isomorphic/IDACall :confused:

[claudiobosticco]

ok, I see in the skinEditor.jsp that the actionURL is modified to that path if the user is authenticated.
I've actually modified skinEditor.jsp to work with my local authentication. Am I actually supposed to do that?

If I comment out the line where the actionURL is modified, the skinEditor doesn't find any skin because it's looking for the template folder inside the skins folders, which is absent in my deployment. On the other hand, also the skinEditorOperations folder is absent.

So I need to ask: is the skin editor actually ready to deploy in our own project? Am I missing some steps?

[claudiobosticco]

I must specify that I'm using maven. Maybe am I missing some maven dependency to have the "template" folder for the skins?

[Isomorphic]

This is intended to work as you're using it - once we have the bug fixed, we'll update here.

[claudiobosticco]

Hello, any news about this issue?

[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.

[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]

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]

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]

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]

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]

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]

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.