Bug to track this issue, for reference:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=294506

 

 

Nicolas,

 

This mailing list is for development of the Web Tools Platform itself. Future questions regarding the JSF Tools subproject (which developed and maintains the Web Page Editor also) would be better directed to the newsgroup or forums. This URL should get you there: http://www.eclipse.org/newsportal/thread.php?group=eclipse.webtools.jsf.

 

There were some fairly significant changes made in this area for Galileo. As you have correctly pointed out, the documentation was not updated to reflect the changes – this was an oversight for which I apologize. I will be logging a bug to track updating of the documentation as soon as I am done attempting to describe what has changed and a little about why, here.

 

First, why were there changes? Well, we identified a couple of issues that we couldn’t ignore and had to address. The first issue was that, due to limitations we imposed on ourselves in the design, it wasn’t going to be a simple matter to write new operations and get them into appropriate plug-ins – they would all need to be “custom operations” or the metadata would have to be included in plug-ins where it really didn’t belong (in short, we wanted Trinidad metadata in a Trinidad plug-in, and our previous design got in the way of that). The second issue was that a “custom operation” could not have parameters, while the “built-in operations” could – this both got in our way and we also saw it as an undesirable design. So we changed things somewhat to address these issues.

 

There is now no difference between our “built-in” operations and “custom” ones – there is one type of operation, and it must be registered via an extension point, and referenced slightly differently in metadata.

 

Before using your own operations, you must register them using the “org.eclipse.jst.pagedesigner.pageDesignerExtension/tagTransformOperation” extension point element. An excerpt of a plugin.xml file registering the “CopyAttributeOperation” follows:

 

<plugin>

                …

                <extension point=” org.eclipse.jst.pagedesigner.pageDesignerExtension”>

                                …

                                <tagTransformOperation

                                                class=”org.eclipse.jst.pagedesigner.dtmanager.converter.operations.internal.CopyAttributeOperation”

                                                id=”CopyAttributeOperation”>

                                </tagTransformOperation>

                                …

                </extension>

                …

</plugin>

 

The value of the class attribute is the fully-qualified classname of the operation. The id is how we will reference the operation in metadata – this id will be qualified with the ID of the plug-in that declares this extension point, which in this case is “org.eclipse.jst.pagedesigner” (so this operation’s qualified id is “org.eclipse.jst.pagedesigner.CopyAttributeOperation”).

 

Metadata that uses this operation must be declared via extension point as described in the help – the basic registration and format of the metadata file is the same as is documented, I will describe the changes to the metadata format below.

 

Where before you would use the above-registered operation like this, “<operation id=”CopyAttributeOperation”><parameter value=”type”/></operation>”, you now need to use the plugin-qualified id, like this:

                <operation id=”org.eclipse.jst.pagedesigner.CopyAttributeOperation>

                                <parameter value=”type”/>

                </operation>

 

There is no longer a “CustomTransformOperation” – you register your operation and then reference it just as is described above for the (previously “built-in”) CopyAttributeOperation.

 

So, for your particular case, you will need to register your operation in your plug-in, something like so:

 

<plugin>

                …

                <extension point=” org.eclipse.jst.pagedesigner.pageDesignerExtension”>

                                …

                                <tagTransformOperation

                                                class=” com.swisslog.spoc7.jsf.common.SpocPageOperation”

                                                id=”SpocPageOperation”>

                                </tagTransformOperation>

                                …

                </extension>

                …

</plugin>

 

Then, your metadata needs to change like so (I’m assuming you performed the above registration in a fictitious plug-in with the id “com.company.product.pluginid” – you will need to change to suit your exact structure, of course):

 

                <operation id=”com.company.product.pluginid.SpocPageOperation”>

                                <!-- your operation can now have parameters here, if so desired -->

                </operation>

 

You’ll also now need to qualify the CopyChildrenOperation – all previous “built-in” operations are registered in the “org.eclipse.jst.pagedesigner” plug-in, so with that as a qualifier, it becomes:

 

                <operation id=” org.eclipse.jst.pagedesigner.CopyChildrenOperation”/>

 

With these changes, you should be back in business. Please feel free to contact me directly should you have further questions directly related to this conversion process. Again, my apologies for the oversight in not correcting the documentation – I am now going to log a bug. (I seem to recall that we DID describe this change somewhere, on some WTP wiki page or in the newsgroup, perhaps, although I can’t seem to locate that announcement at present.)

 

-          Ian (JSF Tools Project)

 

 

Hi

 

 I extended my Web Page Editor in Eclipse Europa by creating a Plugin Project and using Design-Time Tag Metadata.

This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.

Nicolas,

 

This mailing list is for development of the Web Tools Platform itself. Future questions regarding the JSF Tools subproject (which developed and maintains the Web Page Editor also) would be better directed to the newsgroup or forums. This URL should get you there: http://www.eclipse.org/newsportal/thread.php?group=eclipse.webtools.jsf.

 

There were some fairly significant changes made in this area for Galileo. As you have correctly pointed out, the documentation was not updated to reflect the changes – this was an oversight for which I apologize. I will be logging a bug to track updating of the documentation as soon as I am done attempting to describe what has changed and a little about why, here.

 

First, why were there changes? Well, we identified a couple of issues that we couldn’t ignore and had to address. The first issue was that, due to limitations we imposed on ourselves in the design, it wasn’t going to be a simple matter to write new operations and get them into appropriate plug-ins – they would all need to be “custom operations” or the metadata would have to be included in plug-ins where it really didn’t belong (in short, we wanted Trinidad metadata in a Trinidad plug-in, and our previous design got in the way of that). The second issue was that a “custom operation” could not have parameters, while the “built-in operations” could – this both got in our way and we also saw it as an undesirable design. So we changed things somewhat to address these issues.

 

There is now no difference between our “built-in” operations and “custom” ones – there is one type of operation, and it must be registered via an extension point, and referenced slightly differently in metadata.

 

Before using your own operations, you must register them using the “org.eclipse.jst.pagedesigner.pageDesignerExtension/tagTransformOperation” extension point element. An excerpt of a plugin.xml file registering the “CopyAttributeOperation” follows:

 

<plugin>

                …

                <extension point=” org.eclipse.jst.pagedesigner.pageDesignerExtension”>

                                …

                                <tagTransformOperation

                                                class=”org.eclipse.jst.pagedesigner.dtmanager.converter.operations.internal.CopyAttributeOperation”

                                                id=”CopyAttributeOperation”>

                                </tagTransformOperation>

                                …

                </extension>

                …

</plugin>

 

The value of the class attribute is the fully-qualified classname of the operation. The id is how we will reference the operation in metadata – this id will be qualified with the ID of the plug-in that declares this extension point, which in this case is “org.eclipse.jst.pagedesigner” (so this operation’s qualified id is “org.eclipse.jst.pagedesigner.CopyAttributeOperation”).

 

Metadata that uses this operation must be declared via extension point as described in the help – the basic registration and format of the metadata file is the same as is documented, I will describe the changes to the metadata format below.

 

Where before you would use the above-registered operation like this, “<operation id=”CopyAttributeOperation”><parameter value=”type”/></operation>”, you now need to use the plugin-qualified id, like this:

                <operation id=”org.eclipse.jst.pagedesigner.CopyAttributeOperation>

                                <parameter value=”type”/>

                </operation>

 

There is no longer a “CustomTransformOperation” – you register your operation and then reference it just as is described above for the (previously “built-in”) CopyAttributeOperation.

 

So, for your particular case, you will need to register your operation in your plug-in, something like so:

 

<plugin>

                …

                <extension point=” org.eclipse.jst.pagedesigner.pageDesignerExtension”>

                                …

                                <tagTransformOperation

                                                class=” com.swisslog.spoc7.jsf.common.SpocPageOperation”

                                                id=”SpocPageOperation”>

                                </tagTransformOperation>

                                …

                </extension>

                …

</plugin>

 

Then, your metadata needs to change like so (I’m assuming you performed the above registration in a fictitious plug-in with the id “com.company.product.pluginid” – you will need to change to suit your exact structure, of course):

 

                <operation id=”com.company.product.pluginid.SpocPageOperation”>

                                <!-- your operation can now have parameters here, if so desired -->

                </operation>

 

You’ll also now need to qualify the CopyChildrenOperation – all previous “built-in” operations are registered in the “org.eclipse.jst.pagedesigner” plug-in, so with that as a qualifier, it becomes:

 

                <operation id=” org.eclipse.jst.pagedesigner.CopyChildrenOperation”/>

 

With these changes, you should be back in business. Please feel free to contact me directly should you have further questions directly related to this conversion process. Again, my apologies for the oversight in not correcting the documentation – I am now going to log a bug. (I seem to recall that we DID describe this change somewhere, on some WTP wiki page or in the newsgroup, perhaps, although I can’t seem to locate that announcement at present.)

 

-          Ian (JSF Tools Project)

 

 

Hi

 

 I extended my Web Page Editor in Eclipse Europa by creating a Plugin Project and using Design-Time Tag Metadata.

This message may contain legally privileged or confidential information and is therefore addressed to the named persons only. The recipient should inform the sender and delete this message, if he/she is not named as addressee. The sender disclaims any and all liability for the integrity and punctuality of this message. The sender has activated an automatic virus scanning, but does not guarantee the virus free transmission of this message.