Skip to main content



      Home
Home » Eclipse Projects » Eclipse Scout » Neon Version of Scout - Scout SDK Tooling(What's On Your Wishlist?)
Neon Version of Scout - Scout SDK Tooling [message #1715922] Fri, 27 November 2015 12:41 Go to next message
Eclipse UserFriend
With the Neon release of Scout, we need to rewrite a lot of the tooling provided in the Eclipse IDE. The Scout SDK as we know it until Mars will not be the same.
The starting point for this discussion is the current state of the Neon tooling. We have:

* A new Scout project wizard (only one step; see our HelloWorld short tutorial).
* The NLS Editor (very similar to the Mars version).
...and nothing else!

You need to do everything by yourself using the Java Perspective. There is no "Scout Explorer View" and no "Scout Object Properties View". We do not provide all the wizards you had with Mars.

Now is the appropriate time to ask you about the important features you use in the Scout SDK. This forum post contains a priority list of features we plan to provide with the Neon Version.

Feel free to give us feedback. Do you agree with this list? Are you OK with the priority order we propose? Can you imagine work with those features? Have you feedback on the proposed implementation? Have you other ideas?

-------------

1. New scout model inner class in existing java files

It should be possible to create new scout entity in existing java classes. Examples:
* New fields in existing group box.
* New columns in existing tables.
* New menus everywhere it is possible.
* ...

One implementation possibility is to reimplement something we have already in the Mars IDE. With Ctrl+Space you can open the corresponding wizard.

index.php/fa/24095/0/


2. New java class (corresponding to scout model element)

It should be possible to create new scout entity that corresponds to new java classes. Examples:
* New form
* New page
* New outline
* ...

One possible implementation is to use the standard Ctrl+N (eclipse new) wizard or a menu directly on the package.

index.php/fa/24096/0/

In Mars there is also the possibility to call those wizards directly on Java packages in the Packages explorer. Do you use this possibility?


3. Application launchers

It should be possible to start and stop the different application from a central place. In addition there should be a possibility to open the corresponding single page application URL in a browser.

A possible implementation is to have a view where it is possible to bind existing launchers.

index.php/fa/24097/0/


4. Create an a template from an existing GroupBox

It should be possible to transform a field or a group box to a template.

A possible implementation is to start a wizard (similar to Mars) with the Ctrl+1 quick fix when the inner-class is selected.

index.php/fa/24098/0/


5. Scout Outline view of the currently opened class

When a Java Class is opened in the Java Editor, it should be possible to see the Scout Tree corresponding to the current class.

For the implementation, would you prefer a view or a pop-up (like the one you get with Ctrl+O)?

index.php/fa/24099/0/

In the current Scout Tree (in the Scout Explorer), are you using drag and drop to reorganize the tree? Is it something you would like to have with Neon?

-------------

Please use this thread to give us feedback.

The Scout Team needs to have your opinion on the SDK. Without any participation from our community, we might forget to (re)implement an important feature you use in the Mars version of the SDK.

If no feedback comes from your side, we will interpret this as: "Scout SDK is not relevant for me, I do not care".

[Updated on: Thu, 20 October 2016 15:50] by Moderator

Re: Neon Version of Scout - Scout SDK Tooling [message #1715936 is a reply to message #1715922] Sat, 28 November 2015 03:32 Go to previous messageGo to next message
Eclipse UserFriend
will you change or update the scout book too?
Re: Neon Version of Scout - Scout SDK Tooling [message #1715937 is a reply to message #1715936] Sat, 28 November 2015 05:46 Go to previous messageGo to next message
Eclipse UserFriend
yes, we are planning to do that in the coming months.

while we are talking about this topic: we are also planning to merge the application in the scout book with the application in the scout wiki. baiscally we try to improve on both and reduce maintenance for coming scout releases at the same time.

Over time, the Scout documentation will be hosted on Github using AsciiDoctor (replacing LaTex) as described by Jeremie in his EclipseCon session.
Re: Neon Version of Scout - Scout SDK Tooling [message #1715958 is a reply to message #1715922] Sun, 29 November 2015 07:24 Go to previous messageGo to next message
Eclipse UserFriend
Regarding topic 1 (New scout model inner class in existing java files ) and 2 (New java class (corresponding to scout model element) ):

I usually work with the Scout Explorer. I create new elements with the pop-up menu in the Scout Explorer. So the Scout Explorer with the current menus are the most important for me.

Regarding topic 3 (Application launchers):
During development time I use these a lot. The most important for me are the development versions of the launchers (The start, debug and stop buttons). Because I use the Scout Explorer most often, I have to swith back to the project node to see get the product launchers again. And then navigate back to the form I am currently working on.
So I would be a good thing to have these button for the development versions (client and server) somewhere in the IDE so that they are always visible. For example in the button bar.

Regarding topic 4 (Create a template from an existing GroupBox) I dont't use this very often. For me first the place to search for this functionality would be in the Scout Explorer on an element.


Regarding topic 5 (Scout Outline view of the currently opened class) Here I would prefer the Pop-up. I would use it mainly to quickly jump to another place in code withouth changing the contents of the Scout explorer.

I often use the drag and drop option in the Scout Explorer in the tree. Use it to change the order of the fields or to put them in a group box.
Re: Neon Version of Scout - Scout SDK Tooling [message #1715989 is a reply to message #1715922] Mon, 30 November 2015 03:23 Go to previous messageGo to next message
Eclipse UserFriend
Topics 1 and 2 are the most important. These two features save a lot of time in implementing a scout application...
(don't forget CodeTypes and Permissions in your list of elements).

Next important feature is the overview (topic 5). I prefer a view (and I use drag and drop very often).
Re: Neon Version of Scout - Scout SDK Tooling [message #1716027 is a reply to message #1715989] Mon, 30 November 2015 11:27 Go to previous messageGo to next message
Eclipse UserFriend
What about to develope an interface to allow you connect or settup any ORM in the market, like spring data or even better are you planing to develope your own ORM?
Re: Neon Version of Scout - Scout SDK Tooling [message #1716576 is a reply to message #1716027] Sat, 05 December 2015 04:10 Go to previous messageGo to next message
Eclipse UserFriend
One little thing that I figured out when I was setting up a dev pipeline for a Scout project with Luna was that it would be great if you were also generating the test code for the code you're generating... As it's almost always the same (except for the names, prefix, ...) it makes sense to automatically generate it. And this way, if you're using a tool like Sonar, you would start your projects with a 100% test coverage and you know that any drop in that percentage is your fault (and that could help prevent forgetting to implement an important test case).
Re: Neon Version of Scout - Scout SDK Tooling [message #1716682 is a reply to message #1716576] Mon, 07 December 2015 08:54 Go to previous messageGo to next message
Eclipse UserFriend
It seems that the answer I already tried to post a few days ago got lost, so here I go again:

Topic 1:
So far I did this using the Scout Explorer for 80% of the cases and directly in the code for 20% of the cases. The path using Scout Explorer should be supported in the future as well.
I didn't know about support for code recommendation (Ctrl+Space) but that seems a nice addition

Topic 2:
So far I'm using the Scout Explorer for this and think this should be supported in the future as well. Allowing this directly through the package explorer context menu/Ctrl+N is a nice addition but has 2nd priority for me.

Topic 3:
I almost never use the application launchers. To start a product for the first time I used to double click the product file and launched it from there, after that, there is a run/debug config that can be used to start servers/clients with just 2 mouse clicks which was my preferred method. Adding launcher support has lowest priority of the 5 topics mentioned for me (together with topic 4).

Topic 4:
I hardly ever used the scout SDK to create templates. I usually refactor them manually in exactly the way I needed them. For Scout beginners, this is a nice feature but to me has a very low prio (together with topic 3)

Topic 5:
Having a full tree (including all source files) available in the Scout Explorer is a must for me. If a tree view for a single file/class is added, I would prefer this to be a popup view, not a separate view.

Now that the Eclipse dependency in the Scout runtime is gone, are there plans to support both Eclipse and IntelliJ for the SDK?
Re: Neon Version of Scout - Scout SDK Tooling [message #1716836 is a reply to message #1716682] Tue, 08 December 2015 08:08 Go to previous messageGo to next message
Eclipse UserFriend
Urs Beeli wrote on Mon, 07 December 2015 14:54
Now that the Eclipse dependency in the Scout runtime is gone, are there plans to support both Eclipse and IntelliJ for the SDK?


Now that running a Scout Application do not requires Equinox/OSGi we theoretically do not depend on Eclipse Tooling anymore (no PDE, no Tycho and so on).
If you take the Hello-World example: it is a plain java application, the dependencies between the modules are defined in the maven pom. I did not try it, but you should be able to start and edit it from any Java IDE.

For each feature we build with neon, we try to be IDE agnostic. Here some examples:
* FormData generation is a simple java program, that now is integrated in Eclipse IDE (when a form class changes, the FormData class needs to be regenerated) but that could be integrated elsewhere.
* If I am not mistaken, the "New Scout Application" wizard now relies on maven archetype (you could use it from the command line).
* ...

That said, having a good development experience with an IDE goes behind the runtime and the build system. My personal opinion is that "supporting IntelliJ" is again a question of sponsorship. Who is willing to invest time and/or money in Tooling for IntelliJ?
To my current knowledge BSI is evaluating how much tooling for Eclipse IDE is requested to work efficiently with the Eclipse Scout framework (first motivation is that BSI employees are efficient when they work on Scout application projects). BSI has no plan to invest in other IDE Tooling.
The important message is: the door is not closed, but someone has to invest this feature to make it happen.
Re: Neon Version of Scout - Scout SDK Tooling [message #1717342 is a reply to message #1715922] Fri, 11 December 2015 17:44 Go to previous messageGo to next message
Eclipse UserFriend
Quote:
You need to do everything by yourself


I just started a Neon-M3 playground and I remarked that not only the perspective and Views are not around, but in my example also the creation of the FormData and/or the FormField getters are not generated. Is this the actual state or do I miss something to make the generators work?

-Rene
Re: Neon Version of Scout - Scout SDK Tooling [message #1717359 is a reply to message #1717342] Sat, 12 December 2015 01:13 Go to previous messageGo to next message
Eclipse UserFriend
* Creation of FormData: should be available
* Creation of FormField Getters: this was done by the "New FormField" Wizard, which is no longer available.

I double checked the creation of FormData. When I use the Neon.M3 EPP, I get this error in the error log:
eclipse.buildId=4.6.0.I20151029-1100
java.version=1.8.0_05
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.scout.product
Command-line arguments:  -data file:/C:/****/eclipse-scout-neon-M3-win32-x86_64/ws/ -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.scout.product

org.eclipse.core.jobs
Error
An internal error occurred during: "Check if java deltas triggers a IDerivedResourceHandlerFactory".

java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.batch.FileSystem.getClasspath(Ljava/lang/String;Ljava/lang/String;ZLorg/eclipse/jdt/internal/compiler/env/AccessRuleSet;Ljava/lang/String;)Lorg/eclipse/jdt/internal/compiler/batch/FileSystem$Classpath;
	at org.eclipse.scout.sdk.core.model.spi.internal.WorkspaceFileSystem.createClasspath(WorkspaceFileSystem.java:171)
	at org.eclipse.scout.sdk.s2e.ScoutSdkCore.appendPath(ScoutSdkCore.java:107)
	at org.eclipse.scout.sdk.s2e.ScoutSdkCore.appendPaths(ScoutSdkCore.java:97)
	at org.eclipse.scout.sdk.s2e.ScoutSdkCore.createClasspaths(ScoutSdkCore.java:84)
	at org.eclipse.scout.sdk.s2e.ScoutSdkCore.createJavaEnvironment(ScoutSdkCore.java:78)
	at org.eclipse.scout.sdk.s2e.trigger.CachingJavaEnvironmentProvider.getOrCreateEnv(CachingJavaEnvironmentProvider.java:49)
	at org.eclipse.scout.sdk.s2e.trigger.CachingJavaEnvironmentProvider.jdtTypeToScoutType(CachingJavaEnvironmentProvider.java:35)
	at org.eclipse.scout.sdk.s2e.trigger.AbstractDerivedResourceSingleHandler.<init>(AbstractDerivedResourceSingleHandler.java:28)
	at org.eclipse.scout.sdk.s2e.internal.dto.DtoDerivedResourceHandler.<init>(DtoDerivedResourceHandler.java:28)
	at org.eclipse.scout.sdk.s2e.internal.dto.DtoDerivedResourceHandlerFactory.createHandlersFor(DtoDerivedResourceHandlerFactory.java:40)
	at org.eclipse.scout.sdk.s2e.internal.trigger.DerivedResourceManager.createOperations(DerivedResourceManager.java:130)
	at org.eclipse.scout.sdk.s2e.internal.trigger.DerivedResourceManager$P_JavaChangeEventCheckJob.addElementsToQueue(DerivedResourceManager.java:423)
	at org.eclipse.scout.sdk.s2e.internal.trigger.DerivedResourceManager$P_JavaChangeEventCheckJob.run(DerivedResourceManager.java:380)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


Have you also this error in your "Error Log" View?

If you install the M3 Scout SDK in a Mars.1 Eclipse (new name of Mars SR1) it works as expected.

This is definitively a Bug. I will inform the SDK Team. Thank you for your report in the Forum.

[Updated on: Sat, 12 December 2015 05:15] by Moderator

Re: Neon Version of Scout - Scout SDK Tooling [message #1717365 is a reply to message #1717359] Sat, 12 December 2015 03:32 Go to previous messageGo to next message
Eclipse UserFriend
Good morning Jeremie

I can config, I have the same error in the log.

I'll try with Mars...but I think you mean SR1 and not M1 Wink
Re: Neon Version of Scout - Scout SDK Tooling [message #1717368 is a reply to message #1717365] Sat, 12 December 2015 05:14 Go to previous messageGo to next message
Eclipse UserFriend
Starting with Mars, there is no service release anymore. They are called Update Releases: Mars.1 and Mars.2 (next February).

I will correct the typo...
Re: Neon Version of Scout - Scout SDK Tooling [message #1717406 is a reply to message #1717368] Sun, 13 December 2015 02:51 Go to previous messageGo to next message
Eclipse UserFriend
As already mentioned, the most important feature currently missing in Neon is the formdata code (re)generation - at least I couldn't get it working. But I see you're onto that.

After that, the feature I use most heavily is the Scout Properties Editor. It is particularly nice since it not only generates code, but it also gives an overview of what things can be tweaked in each element. This is a big plus for learn-ability.
Then, NLS editor (the ability to create/edit NLS keys from the properties editor is a big time saver too), which is already included. Nice.

I use the scout explorer for browsing, and basically create all new scout elements using the right-click context menu wizards, but I could probably live without it and use the project explorer instead, but well... it's nice to have. Ditto with the product launchers. I haven't really used templates much, and I don't use the CTRL-space code templates.
Re: Neon Version of Scout - Scout SDK Tooling [message #1717735 is a reply to message #1716836] Wed, 16 December 2015 06:49 Go to previous messageGo to next message
Eclipse UserFriend
Jeremie Bresson wrote on Tue, 08 December 2015 08:08
Urs Beeli wrote on Mon, 07 December 2015 14:54
Now that the Eclipse dependency in the Scout runtime is gone, are there plans to support both Eclipse and IntelliJ for the SDK?


Now that running a Scout Application do not requires Equinox/OSGi we theoretically do not depend on Eclipse Tooling anymore (no PDE, no Tycho and so on).
If you take the Hello-World example: it is a plain java application, the dependencies between the modules are defined in the maven pom. I did not try it, but you should be able to start and edit it from any Java IDE.

For each feature we build with neon, we try to be IDE agnostic. Here some examples:
* FormData generation is a simple java program, that now is integrated in Eclipse IDE (when a form class changes, the FormData class needs to be regenerated) but that could be integrated elsewhere.
* If I am not mistaken, the "New Scout Application" wizard now relies on maven archetype (you could use it from the command line).
* ...

That said, having a good development experience with an IDE goes behind the runtime and the build system. My personal opinion is that "supporting IntelliJ" is again a question of sponsorship. Who is willing to invest time and/or money in Tooling for IntelliJ?
To my current knowledge BSI is evaluating how much tooling for Eclipse IDE is requested to work efficiently with the Eclipse Scout framework (first motivation is that BSI employees are efficient when they work on Scout application projects). BSI has no plan to invest in other IDE Tooling.
The important message is: the door is not closed, but someone has to invest this feature to make it happen.


I would really like to see form data generation as a maven plugin or a part of one. It is a really bad practice to commit generated files in your source control and I would prefer to avoid it if possible (also we could use intellij then if we wanted to).

Another thing is that while experienced users don't need the Scout view part, it is really good for beginners... an easy way to introduce it.
Re: Neon Version of Scout - Scout SDK Tooling [message #1717740 is a reply to message #1717735] Wed, 16 December 2015 07:43 Go to previous messageGo to next message
Eclipse UserFriend
The FormData generation engine has exactly no dependency to Eclipse IDE. All the dependencies can be fetched from Maven Central.

I am not sure if we have already a headless Java program to generate them, but nothing speak against it.

As for a maven plugin to do the job: I have heard that someone tried it, but he needed to drop it because of following problem: the shared module doesn't know the client module (the FormData generation cannot be performed as part of the shared build). The client module is built after the shared module, and cannot contribute classes to the shared (which is already built). This is a kind of chicken and egg problem.

As far as I have understood it, the Gradle build system offers more flexibility in this domain. But we have not started any investigation in this area.

Any contribution (for a build tool and/or an IDE) is welcomed. Feel free to start something and to share the result with us. This is an open-source project.
Re: Neon Version of Scout - Scout SDK Tooling [message #1717769 is a reply to message #1717359] Wed, 16 December 2015 10:39 Go to previous messageGo to next message
Eclipse UserFriend
Hi Jeremie

You posted that you will tell the SDK team about this bug (message #1717359). Is it corrected in Neon M4 (which will be available on friday)?

Or do we still need to use the Mars Version of Eclipse?

Thanks

[Updated on: Wed, 16 December 2015 10:40] by Moderator

Re: Neon Version of Scout - Scout SDK Tooling [message #1717781 is a reply to message #1717769] Wed, 16 December 2015 11:29 Go to previous messageGo to next message
Eclipse UserFriend
I checked this today using pre-release of Neon M4 according to these instructions. The form data generation should work properly with Neon M4.
Re: Neon Version of Scout - Scout SDK Tooling [message #1717848 is a reply to message #1717781] Thu, 17 December 2015 05:53 Go to previous messageGo to next message
Eclipse UserFriend
Thank you Mathias

FormData update works in Neon M4 when a new Scout Project is created in M4.

I checked out (from SVN) an existing project (created with Neon M3) into a fresh Neon M4 workspace. FormData update does still not work in this project.

It would be an option to create a new project with M4 and copy all sources from the M3 workspace. I guess this would work. As this is very extensive to do: Does anybody know what the problem is? Is there an option in the project settings which must be changed (I did not found any option that looks as it would be responsable for my problem)?

Thanks
Re: Neon Version of Scout - Scout SDK Tooling [message #1718229 is a reply to message #1717848] Mon, 21 December 2015 08:02 Go to previous messageGo to next message
Eclipse UserFriend
Hi Silvio

If the existing project is still using M3 of the Scout Runtime (you can check this in your pom), it will not work.
The M4 SDK only supports the Scout 5.2.0 M4 Runtime or newer. You cannot use a Scout 5.2 M3 application with the M4 SDK.

To Update your project to M4 you can do the following:

  1. remove the <repositories> and <pluginRepositories> elements in your parent pom
  2. Update the <org.eclipse.scout.rt_version> property to 5.2.0.M4
  3. Update the version of the parent maven_rt_plugin_config-master to 2.0


After that maven will download the Scout Runtime 5.2 M4. In this version there have been some renamings and refactorings which require to organize all imports. For all other changes you can use a newly created project as template.

Does this help?

Kind regards
matthias
Re: Neon Version of Scout - Scout SDK Tooling [message #1718334 is a reply to message #1717740] Tue, 22 December 2015 09:54 Go to previous messageGo to next message
Eclipse UserFriend
Jeremie Bresson wrote on Wed, 16 December 2015 07:43
The FormData generation engine has exactly no dependency to Eclipse IDE. All the dependencies can be fetched from Maven Central.

I am not sure if we have already a headless Java program to generate them, but nothing speak against it.

As for a maven plugin to do the job: I have heard that someone tried it, but he needed to drop it because of following problem: the shared module doesn't know the client module (the FormData generation cannot be performed as part of the shared build). The client module is built after the shared module, and cannot contribute classes to the shared (which is already built). This is a kind of chicken and egg problem.

As far as I have understood it, the Gradle build system offers more flexibility in this domain. But we have not started any investigation in this area.

Any contribution (for a build tool and/or an IDE) is welcomed. Feel free to start something and to share the result with us. This is an open-source project.


Maven plugin is quite a task since none of us has any experience in this area... a small runnable jar from cmdline is also very good Smile
Re: Neon Version of Scout - Scout SDK Tooling [message #1718404 is a reply to message #1715922] Wed, 23 December 2015 07:21 Go to previous messageGo to next message
Eclipse UserFriend
Hello Jérémie

Here is some feedback from me:

1. New scout model inner class in existing java files

This would be an awesome feature I would definitively use a lot! However, the priority is not really that high, because the default JDT proposals and code completions are usually quite sufficient. Writing "public class XXX extends AbstractYYY { [Enter]" does not take that long. Nevertheless it would be very convenient for advanced users. I think, beginners would prefer the SDK outline tree (see point 5).

Some additional proposals:
* SDK code completions should allow to easily override getConfiguredXXX methods (without having to write "getConfigured[Ctrl-Space]".
* There should be an action to create a public getter for a field or column class.

3. Application launchers

I never use those, but I know of users who do frequently.

4. Create an a template from an existing GroupBox

I didn't even know this function existed Wink

5. Scout Outline view of the currently opened class

I think it would be very important to provide the tree structure view, at least for forms and tables. Especially for new Scout users, this is extremely helpful. I know of many users who still regularly create and manage forms and tables with this view. Sure, the more advanced you get, the more you directly edit the Java code. But the possibility to do both simultaneously is one of Scout's biggest strengts. Drag & drop in the tree is also an important function, because it not only moves the code in the file but also changed the @Order numbers accordingly.

I don't know if I would use the Ctrl-O popup, because the plain JDT Ctrl-O popup already provides all information i need (including methods and filtering). What would be the benefit (apart from different icons)?

Beat
Re: Neon Version of Scout - Scout SDK Tooling [message #1718408 is a reply to message #1718229] Wed, 23 December 2015 08:17 Go to previous messageGo to next message
Eclipse UserFriend
@Matthias Villiger

Thank you. Changing the 3 mentioned points seems to work. At least the ProcessingException is still there, but has a different package name (that's what you mentioned -> need to update imports).

I will clean up the remaining imports now and do all other renamings.
Re: Neon Version of Scout - Scout SDK Tooling [message #1718780 is a reply to message #1715922] Wed, 30 December 2015 03:25 Go to previous messageGo to next message
Eclipse UserFriend
I forgot to write here, that with the Neon M4 release, some support for the point "1. " (New scout model inner class in existing java files) have been added to the IDE.

Proposals in GroupBox classes:
index.php/fa/24443/0/
Proposals in Table classes:
index.php/fa/24444/0/

Do not hesitate to try the features out and to give us feedback about it.
Re: Neon Version of Scout - Scout SDK Tooling [message #1718781 is a reply to message #1718404] Wed, 30 December 2015 03:48 Go to previous messageGo to next message
Eclipse UserFriend
Beat, thanks for your detailed inputs.

Beat Schwarzentrub wrote on Wed, 23 December 2015 13:21
* SDK code completions should allow to easily override getConfiguredXXX methods (without having to write "getConfigured[Ctrl-Space]".


This is something that works great with Snipmatch. I did a prototype last year:
https://www.bsi-software.com/en/scout-blog/article/snipmatch-a-better-template-engine-for-the-eclipse-ide.html

I should check if we can use it with Neon...

Beat Schwarzentrub wrote on Wed, 23 December 2015 13:21
* There should be an action to create a public getter for a field or column class.


Tooling to generate missing fields and columns getters is definitively something that I could also use. My solution for the moment is to copy the Classes from the outline view and to past the list in Excel. I have an Excel formula that generates the corresponding Java Code:
index.php/fa/24445/0/

For columns:
=CONCATENATE("public ";A1;" get";A1;"(){ return getColumnSet().getColumnByClass(";A1;".class);}")

For fields:
=CONCATENATE("public ";A1;" get";A1;"(){ return getFieldByClass(";A1;".class);}")
Re: Neon Version of Scout - Scout SDK Tooling [message #1719017 is a reply to message #1718781] Mon, 04 January 2016 08:13 Go to previous messageGo to next message
Eclipse UserFriend
Jérémie, thanks for your reply.

Regarding Snipmatch: This looks nice (I use the LOG template frequently, and it would be great if I didn't have to import it in every workspace). However, I thought more of an automatic extraction of the available "getConfigureds" from the super class, without manually defining templates for each one. Just like the old SDK did it in its configuration view by providing a field for each method annotated with @ConfigOperation.
Re: Neon Version of Scout - Scout SDK Tooling [message #1720038 is a reply to message #1718780] Wed, 13 January 2016 16:59 Go to previous messageGo to next message
Eclipse UserFriend
Quote:
I forgot to write here, that with the Neon M4 release, some support for the point "1. " (New scout model inner class in existing java files) have been added to the IDE.


Would it also be possible to add the custom template fields as they were proposed till Mars?
Re: Neon Version of Scout - Scout SDK Tooling [message #1720443 is a reply to message #1720038] Mon, 18 January 2016 11:37 Go to previous messageGo to next message
Eclipse UserFriend
Hi René

I am not sure which custom template fields you mean.

If you mean e.g. a custom group box (like AbstractMyCustomGroupBox extends AbstractGroupBox), then you can choose this super class when creating a new group box using the content assist: After ctrl+space and selecting the group box template you can navigate to the super type using the tab-key. There you will see all matching abstract classes available on the classpath of the currently open editor.

If you mean really custom widgets for which nothing existed in Scout so far, the answer is no. Such elements will not be available out of the box. But it can be extended by writing a plugin that provides a proposal computer adding your custom widget template

Does this answer your question?
Matthias
Re: Neon Version of Scout - Scout SDK Tooling [message #1720449 is a reply to message #1720038] Mon, 18 January 2016 11:55 Go to previous messageGo to next message
Eclipse UserFriend
Hi René

I am not sure which custom template fields you mean.

If you mean e.g. a custom group box (like AbstractMyCustomGroupBox extends AbstractGroupBox), then you can choose this super class when creating a new group box using the content assist: After ctrl+space and selecting the group box template you can navigate to the super type using the tab-key. There all abstract groupbox classes are displayed and you can choose your template class as super type.

If you mean really custom widgets for which nothing existed in Scout so far, the answer is no. Such elements will not be available out of the box. But it can be extended by writing a plugin that provides a proposal computer adding your custom widget template to the content assist list.

Does this answer your question?
Matthias
Re: Neon Version of Scout - Scout SDK Tooling [message #1720513 is a reply to message #1720449] Tue, 19 January 2016 01:48 Go to previous messageGo to next message
Eclipse UserFriend
Hi Matthias

I was talking about the first point (AbstractMyCustomGroupBox) . I didn't know about the solution you propose, I will test.

Thank you
Re: Neon Version of Scout - Scout SDK Tooling [message #1742480 is a reply to message #1715922] Fri, 02 September 2016 05:04 Go to previous messageGo to next message
Eclipse UserFriend
After getting into it, I have come to the opinion that the current SDK Tooling is sufficient to work effectively. I am not really missing anything. In fact the CTRL+SPACE approach is much more fluent to me.

Keep up the good work.
Re: Neon Version of Scout - Scout SDK Tooling [message #1742519 is a reply to message #1742480] Fri, 02 September 2016 11:44 Go to previous message
Eclipse UserFriend
A N

Thanks for your positive feedback and encouragement.

Matthias
Previous Topic:Clearing a wrapped form field
Next Topic:[NEON] Login not working
Goto Forum:
  


Current Time: Mon Jul 21 13:38:52 EDT 2025

Powered by FUDForum. Page generated in 0.29657 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top