as I have not had time to maintain this blog for a long time and am receiving quite a lot of spam comments, I unfortunately missed the notification about your valid comment. The site hierarchy addon I was talking about can be found on GitHub at https://github.com/Acosix/alfresco-site-hierarchy. I believe I did see your message on the forum and did reply to it, but due to the amount of activity on community.alfresco.com I cannot find it right now to verify. Allowing multiple parents would technically be only a small change in the multiplicity of the parent-child associations. Taken together the UI, backend changes and any adaptions to secondary features should all be doable in less than a day. The limitation to single parents primarily resulted from the requirements of the customer for which I initially developed this addon.

Regards
Axel

We have conversed before through the Alfresco forums. I had asked some questions and during the course of the interactions you had pointed out the add-on made by you to achieve Site hierarchies over and above a flat list of Alfresco sites.

I’ve been trying to use the forums to ask you a query regarding the add-on. I am not sure if you are receiving any notifications so I thought I will use this contact form to get in touch with you.

I’m sorry for troubling you like this but I am a little desperate as I have to give an update to my supervisors. Essentially, my supervisors would ideally like having a mechanism of allowing a project to have multiple parents. Because a system component they design can be used as a sub-component in multiple bigger systems.

I was wondering how much effort would it be to actually tweak your plugin for this or whether it is already possible. Looking forward to your reply. And please accept my sincerest of gratitude for the help already rendered by you in the forums.

Best,
Kaustubh

nice to see somebody addressing a long standing issue.

Looks like you have come up with with a more or less clean and finished solution which is ready to be applied against the official sources. I have to say I’m quite curious to see how things evolve – especially whether and when your changes will make their way into the official Alfresco source repository.

cheers
Andreas

having a API library function is what I am aiming for too. In my first approach I dove into the RhinoScriptProcessor and changed the way import-tags are handled, the two major changes being that scripts would no longer be merged but simply executed in sequence and the import tag could be in a line comment at the start of the file, thus no longer messing up syntax validation. The changes were actually not that extensive as I first believed they would be. We’ll see how much hassle implementing a library function entails – I hope to get around to doing this within the next two weeks…

I think it’s best to use a simple node.js style require(“somescript.js”) command and parse it the same way as the current xml import statements are parsed before script compilation.

To have support for AMD (https://github.com/amdjs/amdjs-api/wiki/AMD) style module definitions would be nice but I don’t think it’s practical with the way scripts are executed in Alfresco.

please replace the import “tag” with a library call.

In fact, this is bugging me far more than the embedded debugger.

You may want to have a look at:

http://code.google.com/p/share-extras/issues/detail?id=64
http://stackoverflow.com/questions/8124906/alfresco-debugger-cannot-open-js-including-an-import-tag/8799964

cheers
Andreas

I agree, Milestones / Snapshots are not practical for regular usage – but the stable Juno will be released in June this year so this will be available to the general developer pretty soon. This is my current pet project and I will be looking into expanding this to the Surf layer as well as providing an alternative import mechanism for JavaScript – the current one produces a ton of syntax errors and scripts using it can effectively not be properly debugged.

The debug transport protocol is a generic JSON based-format that is not dependant on Rhino or Eclipse. Should Alfresco switch to Nashorn – and I figure this is yet a very long way in the future (when JDK 8 actually has become the major version used in production by customers) – only the adapter to the engine should need to change. But I’d assume before other IDEs reuse the transport protocol and engine adapter of Eclipse, they’d be developing their own.

Regards, Axel

the rhino embedded debugger definitely has its drawbacks, and uniform debugging even providing more features !) surely is something we should aim at.

This is all pretty much bleeding edge today. Thats fine with me in general, although I don’t want to try eclipse milestones or snapshots for day to day work.

I really appreciate reading your experiences, and I’m curious how this will all work out.

I see a few hurdles ahead before this can go “mainstream”.

Debugging (rhino) server side javascript in the alfresco world applies to surf apps (such as share) as well. Should not be a big deal getting this all to work in the surf environment I guess.

I don’t know much about the debugging protocol used and how it depends on rhino or eclipse. Not everybody is using eclipse (I do), and alfresco may choose to replace rhino with nashorn one day.

cheers
Andreas

danke für diesen Beitrag! Ich würde vorschlagen, diesen Beitrag direkt an Alfresco weiterzuleiten, so dass der Debugging-Support Standard in Alfresco 4.x werden kann und z.B. per einfacher Konfiguration und Kopieren der Eclipse-Bibliotheken aktiviert werden kann.

Danke und viele Grüße,
Jens Goldhammer