xwiki velocity script development tipps&tricks?

Description
woecki
Posts: 43
Joined: Tue Mar 30, 2010 8:55 am

xwiki velocity script development tipps&tricks?

Postby woecki » Mon Jul 30, 2012 11:50 am

Dear community,
Writing Polarion ALM wiki pages/scripts is a bit tedious once scripts gets >20 lines (number may vary to personal preferences :-)).
It's so much try & error as i don't know anything but "trace-output" to follow program flow & variable monitoring.
How do you write scripts? Any tipps & tricks you're willing to share? I assume there's no way to connect polarion/xwiki & an IDE (there's an old posting regarding XEclipse covering that)?
br woecki
Last edited by woecki on Tue Jul 31, 2012 12:10 pm, edited 1 time in total.

engeleb
Posts: 199
Joined: Wed Aug 09, 2006 10:55 am

Re: xwiki velocity script development tipps&tricks?

Postby engeleb » Mon Jul 30, 2012 2:43 pm

Hi Woecki,
When writing bigger scripts I usually use two tabs: One to edit and the other tab to view the result.
Like that you don't have to locate the correct spot you were editing in the Wiki page over and over again.

If you don't mind the effort to setup an environment for Plug-In development and having to restart the server you could use a Plug-In to contribute Java objects to your Wiki page and move all complexity into that Java objects.
Like that you can implement Java code to do all the complex processing and use Velocity to define how the data is rendered only (actually that's how Velocity is intended to be used).

See http://extensions.polarion.com/polarion/extensions/extension.jsp?extension=PE-174 for an example how to contribute Java objects to the context of Wiki pages.


Best Regards,
Benjamin

woecki
Posts: 43
Joined: Tue Mar 30, 2010 8:55 am

Re: xwiki velocity script development tipps&tricks?

Postby woecki » Wed Aug 01, 2012 8:30 am

Hi Benjamin,

Thanks for the tipps!
Regarding Plug-In development: as scripts sometimes evolve over time or are implemented by end users before they become "common property" we would have to re-implement things. And scripting allows fast&easy customization/adoption while a plugin requires a lot of in-front thinking to make it generic enough ;-). But i'll take that into consideration in the future, thanks for the hint!

br woecki

JoernTietjen
Posts: 36
Joined: Tue Jan 10, 2012 2:08 pm
Location: nr Hamburg, Germany

Re: xwiki velocity script development tipps&tricks?

Postby JoernTietjen » Wed Aug 01, 2012 8:34 am

Hi all,

yes, writing and debugging larger scripts can be sort of painful.
You go back to the good old times of printf-debugging and #set($debug) statements in your code.
The API is sparingly documented and my personal experience from contacts to the Polarion technical support are rather discouraging.

However, IMHO the need for complex scripts is an indication that things take the wrong direction: you pay a considerable amount of money for a tool which needs such big extensions? Is it the core competency of your company/department to enhance a commercial OTS tool? Do you make any profit from spending effort for extension development?

I've seen a couple of POP extensions which are complex and brilliant from an engineering point of view but I would expect them to be developed by the Polarion R&D department not by Polarion customers.
Additionally, complex extensions tend to make more use and assumptions on the inner API of Polarion. E.g. the HiveMind framework is used in Polarion. HiveMind has been retired in 2009 and may be silently replaced by another service framework in future Polarion releases. If your personal extension relies on any Polarion API which is changed with a new release, you are lost (or need to spend more effort on extension maintenance).
Also, Polarion neglects any liability for POP extensions gracefully provided by Polarion users (which from their perspective is a reasonable thing to do).

So, my bottom line is: keep your personal extensions lean and simple. If it gets too complex write an enhancement request to Polarion and tweak them from time to time to implement it ;-)

Just my two cents.

Regards
Joern

woecki
Posts: 43
Joined: Tue Mar 30, 2010 8:55 am

Re: xwiki velocity script development tipps&tricks?

Postby woecki » Mon Aug 06, 2012 8:58 am

Hi Joern,
Well said! I'll keep that in mind too.
br woecki

update 2012-08-17
imho a big obstacle when developing macros is a defect in polarion that requires a wiki page containing macros to be opened once after polarion restart to make it include-able via #includeMacros or $includeForm. i got the info from polarion support that this bug will be fixed in polarion 2012 sr2, end of august. just to let you know ...

JoernTietjen
Posts: 36
Joined: Tue Jan 10, 2012 2:08 pm
Location: nr Hamburg, Germany

Re: xwiki velocity script development tipps&tricks?

Postby JoernTietjen » Thu Dec 06, 2012 11:16 am

Hi woecki,

in the beginning of having such a great time with Polarion :wink: I also suspected that macro file inclusion only worked for files being opened at least once since the server boot.
However, I learned that I was wrong and this behaviour had been caused by providing wrong include paths in the wiki pages which were supposed to load the macros.
The correct syntax is
#includeMacros("<projectid>/<space>.<module>")

This works fine for me.

However, it has been difficult for me to detect my fault because Polarion includes a named macro file from any location if it once had been opened explicetly after boot on the server e.g. for editing.

HTH and reagds
Joern

woecki
Posts: 43
Joined: Tue Mar 30, 2010 8:55 am

Re: xwiki velocity script development tipps&tricks?

Postby woecki » Tue Dec 11, 2012 12:55 pm

hi joern,
your post made me re-test the whole mess and you're absolutely right.
now i'm just wondering how DPP-33162 (http://downloads.polarion.com/downloads ... items.html) was ever accepted as a bug and finally got fixed.
anyway, thanks a lot for taking the time to share your wisdom,
br woecki

martins
Posts: 181
Joined: Thu Nov 05, 2009 3:24 pm

Re: xwiki velocity script development tipps&tricks?

Postby martins » Thu Dec 13, 2012 8:17 am

Hello Joern and Woecki,

could you please explain what's in your opinion a "wrong" include path?

We also struggle with this problem for a long time now. IMHO with Polarion 2012 SR2 it became a bit better (it doesn't occure on as many pages as before, but it still occures in some cases).

In most of our Wiki pages we use the {includeForm} macro as mentioned in the "Detailed Syntax Help" of Polarion where it says:
The {includeForm} macro inserts content from another page into the current page.

{includeForm:ProjectName(optional)/SpaceName(optional).PageName}

The {includeTopic} macro is an alias for the {includeForm} macro.


Do you think it's better to use "#includeMacros" instead of "{includeForm}" or do you think it's always necessary to use the long path syntax (containing Project-Id plus Space-Id) instead of omiting them when the referenced page is in the same space?

Kind regards

Martin

woecki
Posts: 43
Joined: Tue Mar 30, 2010 8:55 am

Re: xwiki velocity script development tipps&tricks?

Postby woecki » Thu Dec 13, 2012 3:27 pm

hi,
"wrong" is anything but e.g. "{includeForm:_default._macros}" where "_default" is the space and "_macros" is the page name.
i don't wana test any combination, but i saw wrong space name ("default" instead of "_default") or wrong format (".._default/_macros}" and in any case the include worked after the "_macros" page was opened once, which led people to the impression that there is a polarion bug which prevents macros from being included properly. in reallity just the include was done wrong.
we extremly rarely include from other projects to avoid dependencies, so we use "{includeForm:_default._macros}".
for simplicity we do not distiguish between #includeMacro and {includeForm.
just my 0.02€.
br

JoernTietjen
Posts: 36
Joined: Tue Jan 10, 2012 2:08 pm
Location: nr Hamburg, Germany

Re: xwiki velocity script development tipps&tricks?

Postby JoernTietjen » Thu Dec 13, 2012 3:53 pm

Hi folks,

when I started writing macros I used an existing macro (don't remember where it came from) and modified it.
However, this 'template' used a bad path definition ('/' instead of '.' to separate module from space) but it worked as long as I had been editing it so it was loaded by the server.
Trouble started when the macro was supposed to be invoked after the server reboot and nobody had been editing it before invocation.

Because the implicit path resolution algorithm in Polarion may fool you in selecting a macro file (of same name in different locations) which you did not expect to be included I would recommend to always use full qualified paths in the include statement to avoid ambiguities.

I factored out a bunch of macros to a specific macro library project so any regular project can reuse these macros. As a consequence I need to use full qualified paths anyway.

BTW, I prefer the use of #includeMacros over {includeForm} because the latter is a macro where the implementation is somewhat fuzzy to me but the former is a self explanatory programming-language-style statement. However, this is a personal preference and the semantics of both options may be equivalent.

Regards,
Joern

riguy724
Posts: 1
Joined: Thu Mar 03, 2016 10:20 pm

Re: xwiki velocity script development tipps&tricks?

Postby riguy724 » Fri May 06, 2016 4:54 pm

Sorry to revive a dead thread here, but I think a development process for velocity reports / macros (as well as writing scripts, plugins etc...) is super important when working with Polarion. I've developed somewhat of a method of doing this with a combination of some bash magic, eclipse, watching of the jobs logging directory and direct inclusion of the Polarion platform .jar files, that I think is really good.

Just posting here to start promoting some discussion on this again and was planning to make a new thread to capture this process is the coming week or two here.

@Joern can you comment any further on the use of #includeMacros? It seems that this behavior is now deprecated according to the Polarion documentation, but I just thought I'd get some more feedback on your experience with this before recommending against it. It has been a few years since you posted that :D

Thanks,
--

Chris

JoernTietjen wrote:
BTW, I prefer the use of #includeMacros over {includeForm} because the latter is a macro where the implementation is somewhat fuzzy to me but the former is a self explanatory programming-language-style statement. However, this is a personal preference and the semantics of both options may be equivalent.

Regards,
Joern

sergeD
Posts: 23
Joined: Tue Feb 05, 2013 9:24 am

Re: xwiki velocity script development tipps&tricks?

Postby sergeD » Fri May 27, 2016 12:54 pm

Chris, yes old post ..

With Polarion 2016, it has been introduced 2 Two new Classic Wiki macros to replace the existing {includeForm} and {includeTopic} macros. The old macros have issues that negatively impact performance. If you have pages using these now deprecated macros, you’ll want to update to use the new ones. Check Syntax Help for Classic Wiki for usage details.

{include-macros} – includes macros from the specified page without rendering its content
{include-page} – includes content from the specified page and allows use of Velocity variable in the page attribute

Warning: It is not a revival of the old #includeMacros ..It is the... {include-macros}


Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: Google [Bot] and 10 guests