Soy: Improvement suggestion: Global declaration of custom functions

[jensrutschmann]

Hi,

(this is related to issues #2 and #7)

I'm doing a lot of soy template development on top of Atlassian products such as the wiki software Confluence. Atlassian provides some custom functions that are always available in soy templates, such as "getText".

In this scenario it is quite cumbersome if I need to declare these functions in each and every template file again and again. Please consider adding a list or something where I can globally declare custom functions.

Thanks a lot and great plugin btw. !

Best regards, Jens

[vtst]

Hello,

Thanks for your feedback. The function declarations are shared between all the .soy files of a project. It means that you create one soy file in your project that contains the function declarations, and then use the function declarations in all the files of your project. If you want to share the same functions between several projects, you may create a specific project for the function declaration file, and add this project in the referenced projects of every project which needs it.

Does it answer to your need?

Vincent

[jensrutschmann]

Hi Vincent,

yes this helps somewhat. The only disadvantage with this approach is that one has to keep such a project in each workspace and needs to add references every time one creates a new project or imports it from SVN etc.

In our company we use maven based projects, so the eclipse project definitions are not under version control but automatically created from the maven POM file when checking out a project. That's why I was asking for a place to define the functions outside of "project code".

Would it be possible to ship these function definitions as an additional eclipse plugin by using an extension point ?

Best regards, Jens

[vtst]

Ok, I see your problem. I'll think about in order to find a simple solution. How do you manage this for other languages (e.g. Java configuration)?

[jensrutschmann]

Hi Vincent,

the java settings like compiler level or library dependencies are defined in the maven pom.xml and automatically converted to eclipse project settings (this is done by the m2e plugin).

Another possibility would be to let users add their own custom function declarations using a page in the eclipse preferences. For example the veloeclipse plugin does this for velocity macros. I'm not exactly sure where these preferences are stored (probably the workspace) but I guess that would be the most easy way.

Thanks for considering it ! Jens

[Waxolunist]

Sorry to intervent, but storing these functions in eclipse or worse in the workspace, does not solve the issue of having more than one workspace or more than one eclipse installation or more than one team member.

I am a confluence plugin developer as well, and since the last update I don't want to miss this plugin anymore. Very good work. I declared a small file functions.soy, addded it aside to my other soy files in every project.

It looks as follows:

{namespace FUNCTIONS}

// @function docLink 1

// @function getText 1 1

// @function contextPath 0

This does probably change once or twice a year (far less often than I start new workspaces or update/reinstall my eclipse installations), so I don't think there is any need to have something else.

Or you create a small project somewhere on your disk and reference it in every workspace. Then you don't have this in your plugin and can manage it in your code version system (with settings, classpath etc.) in one place. If you start a new atlassian plugin than this project is just 3 clicks away from being imported. You don't pollute your pom. Every other solution I can think of is far less intuitive. The project builds, compiles and runs with or without error markers in the editor. If a new developer wants to get rid of these error markers, a 2 minute explanation or 3 lines in the wiki will help. I just tested this. A project with only the functions.soy in it as reference to another plugin. Works like a charm.

Kind regards Christian

[vtst]

Hello,

Thanks for your feedback. I basically thing that the approach you describe is indeed the best one. This is why it is the one which is currently supported, and you can be sure it will continue to be supported. However, I understand that some people may have specific constraints, this is why I'm thinking to a second solution (that will probably be an include file whose path will be specified in a preference page).

Best

Vincent