Michael K. Bergman wrote:
Hi Rob,
Very helpful tips; see below.
Robert Jones wrote:
Michael K. Bergman wrote:
The ODS main menu is based on the ods-bar framework with associated
code based in ods_bar.vspx, ods_bar.xsl, ods-bar.css and related ones
having to do with user instances. ods_bar.xsl appears to be the main
one.
As an ODS sys admin, it is possible to change menu labels via the ODS
UI using the Site Settings -> Application Menu dialog. However, the
distributed menu option 'Discussion' is not provided there, and there
is a difference in handling apps (e.g., Briefcase) vs profile info
(e.g., Tags).
Because the functions below are not possible via the ODS UI (or if
so, I have not found them! :) ), I have been probing the ODS source
code attempting to:
1. Add new menu links
2. Remove some of the existing ones
3. Change menu item orders, and
4. Modify the Discussion label.
I have been trying to trace code and make mods in various locations,
to no effect. I have even gone so far as to try modifying
DB.DBA.WA_GET_APP_NAME directly through Conductor and in
hosted_services.sql.
Mike,
are you making use of trace_on(<thing>) ?
No, I'm not; this is the first I have heard of it. If you could point
me to some documentation, that would be great.
Mike,
http://docs.openlinksw.com/virtuoso/fn_trace_on.html
personally, I find it particularly useful to enable some of these,
'errors' is a good one, and 'client_sql' can be also.
If you run Virtuoso in debug mode (-df or +debug +foreground) all
tracing output will go to the console (it also goes in the log file).
But the second benefit of debug mode is using dbg_obj_print(). It takes
any parameters and will send them to the debug console, very useful for
debugging random vectors and such like. Can also help you find you
place in the code.
Can anyone provide guidance about where I should next look regarding
these questions?
I haven't looked into the exact location of this yet so I can't say
whether you are in the right/wrong place, however, more generally when
using VSPX sources you are subject to compilation caching. You may
have thought you edited the right thing but nothing happened. In most
cases changes are automatically detected, but occasionally you have to
"stale" the XSLs involved (especially when they are included at depth)
using xslt_stale() but you need to know the URL used internally which
isn't always obvious. If in doubt a server restart is a surefire way
to test this.
Ah, I very much suspected this, though I was locally clearing out
browser cache's to no avail. My suspicion was further confirmed when I
saw some changes appear after re-starting the system overnight.
Please do provide general guidance on this one. I suspect if I am doing
interactive development, that I will want to "stale" the XSLs on a
routine basis. (Is any similar process recommended for SQL changes as
well?)
You do not need to do this for general SQL, only XSL-style
transformation resources like those used in VSPX.
see:
http://docs.openlinksw.com/virtuoso/fn_xslt_stale.html
Where are your XSLs coming from?
If DAV then there is the "virt://..." style URI, but from the file
system its "file://...". If you are trying to stale an included sheet
then you will probably have to stale sheets from that level upwards.
Rob.
