We’ve just released a new Servoy Module called “Documentorium” that will help you to easily document your Servoy solutions.
You can read all about it here: http://bobcusick.blogspot.com/
A couple of things to note: it requires Servoy 5.2 or higher (INCLUDING 6.x); and if you have a HUGE solution, make sure you have LOTS of RAM to allocate to Servoy/Java!
Any feedback or suggestions welcome!
Amazing stuff!
Congratulations Bob, very well done!
What are the advantages vs. using JSDoc?
Thanks, Nicola!
NOTE: If you’re trying to document a large solution - make sure you have PLENTY of RAM allocated to Servoy/Java. Documentorium creates an in-memory map of your solution so it can do the cross referencing.
ryanparrish:
What are the advantages vs. using JSDoc?
JSDoc is great for documenting your methods - and that’s where you put the code - in side your method header.
Documentorium goes farther, in that it will document your SOLUTION (elements on forms, what method is linked to what element, relations, valuelists, etc.)
Love this idea Bob - been a missing link for us for a while in terms of fully understanding our own solution.
Bought Documentorium yesterday but since we had the Jave v26 issue to deal with we were unable to install it until today. However right off the bat we have a problem.
Because we dont use the Servoy menu in our solution I have added the module form as a form in our Admin tab panel, and run it from there. We get this error immideately:
TypeError: Cannot read property "name" from (E:\Dropbox\ServoyWorkspaces\WorkSpaceJuly2011\cw_mod_documentorium\forms\cw_mod_DOCUMENTORIUM.js#1138)
TypeError: Cannot read property "name" from (E:\Dropbox\ServoyWorkspaces\WorkSpaceJuly2011\cw_mod_documentorium\forms\cw_mod_DOCUMENTORIUM.js#1138)
at E:\Dropbox\ServoyWorkspaces\WorkSpaceJuly2011\cw_mod_documentorium\forms\cw_mod_DOCUMENTORIUM.js:1138 (buildRefByObjects)
at E:\Dropbox\ServoyWorkspaces\WorkSpaceJuly2011\cw_mod_documentorium\forms\cw_mod_DOCUMENTORIUM.js:197 (documentSolution)
Could this be because we are running it in a tab in our solution Bob? Is there another way to do it?
EDIT: A lot of our tab forms don’t actually have names (only the actual containsForm name and the tab panel name of course) so perhaps this code is expecting every form in every tab to have a name property set too?
I’ve also now run the cw_mod_DOCUMENTORIUM form from a button on my solution too with the same error.
Ian,
Let me noodle this - why don’t you email support@clickware.com - and we’ll pick up the thread there.
THANK YOU!
just open your smart/debug-client (and login, If you have to)
than navigate in developer/Eclipse to that form, hit CTRL-L and you’re there.
Harjo:
just open your smart/debug-client (and login, If you have to)
than navigate in developer/Eclipse to that form, hit CTRL-L and you’re there.
Yep I did open it that way to Harjo with the same resulting error!
Thanks for the suggestion.
Just a follow-up to fellow readers - it turns out that Ian had a whole bunch of “phantom” forms that had tabpanels linked to forms that no longer existed…
Thanks for Ian for being such a trooper and going through the debug process!
Follow up from Bob’s post.
Yep, it turns out that we had a number of forms that had been duplicated during development and become orphaned. Tab panels had been duplicated and in some instances the forms that were contained therein were renamed etc. So without error traps for it - where tabs were found (with dupe names and where forms had no name) the tool crashed without warning. We traced it with some debugging and Bob’s guidance. When the rouge forms were renamed / deleted as appropriate the tool began to run.
Problem 2: Documentorium runs much of its functionality in memory, so as Bob suggests in his announcement you need a big lump of RAM if you have a large solution. We have currently 612 forms and unfortunately Documentorium runs out of RAM and creates either an out of memory error or crashes the system. I have 4G RAM with 3.2G available after OS, and I have made 1024 available to JAVA like this
-Xms256m
-Xmx1024m
-XX:MaxPermSize=256M
Which is not enough for our solution. I have tried -Xmx allowing 1500M, 2048 ec but JAVA complains and will not allow anything greater than 1024 as far as I can tell. This memory monkeying is new to me so if anyone has a recommendation on how to get JAVA to swallow more memory I’d appreciate it.
We’d REALLY like to use this tool as its output is EXACTLY what we need as a desktop reference to our own solution during development and as new developer documentation for the structure and design. Bob has refunded us because of the this issue but we’d really rather get it working!
Best of luck with it Bob - hope you can tweak it somehow?
Cheers
Ian
Part of the issue is that I didn’t want to have to include a database, a connection, etc, etc.
If you tweak the code, you can create a database and write the records to it, and then after it’s done, go back and build the report.
Cheers!
on a 32bit vm -Xmx1500m still should work just fine i believe
The only thing is that the total space can’t grow above the 2GB…
if you really want to use all of your systems memory and also be able to give java more then 2GB in total then move to a 64bit os and 64bit vm
Bob: can’t you use the hd a bit? So that you flush out stuff to disk?
jcompagner:
on a 32bit vm -Xmx1500m still should work just fine i believe
The only thing is that the total space can’t grow above the 2GB…
if you really want to use all of your systems memory and also be able to give java more then 2GB in total then move to a 64bit os and 64bit vm
I got it up to 1200m but it fails there after and its the same on my 64bit laptop with 4g ram (might be 32gig JAVA though? Anything over and eclipse complains with the -1 error.
Just tried Documentorium at that memory setting (1200m) and it still seizes up so probably only resort is to tweak the code to spool to tables or similar.
Johan,
Yes, good idea. I should dump out the HTML. I’ll have to think about how that could work - since I iterate over every object and script in the entire solution - Servoy has to load/unload ALL objects as well. I am using arrays to store the HTML data (rather than just a huge, in-memory string).
Is it more efficient to build a bunch of arrays in memory, and then just build all the HTML in the end? I also think it’ an issue of a HTML field displaying all that data as well?
Perhaps it will JUST create the HTML on disk? Would that be more efficient (memory-wise)?
i think concating a huge string will use more memory then just purely holding on to the data.
Then i guess with some use of direct java code you could concat the string by writing it directly to disk…
(using things like FileOutputStream and/or Writers)