Eclipse Community Forums: EGL Development Tools

Home » Archived » EGL Development Tools » Getting Started(Where Are the Getting Started Documents?)

Tue, 29 November 2011 09:08

Eclipse User

I know I'm coming late to the party, so I need to get up to speed as quickly as possible. I already created a simple JS project and deployed it to the test server and all went fine. Now I need to create a client/server application and I'd love a little help on getting started. I think I'll need a quick 'fresher on deployment. I see folders in my project called client, server and common, but shouldn't I really be using my own package names, with reversed-domain naming to avoid collisions with other people's stuff?

In any event, what determines where the various packages and parts get deployed? I want to write a Rich UI handler that calls a service that does some database I/O. Where's the best example of how to do that? Because then I can start doing some serious acid testing.

Joe

Re: Getting Started [message #759720 is a reply to message #759654]

Tue, 29 November 2011 13:32

Eclipse User

Regarding package names... when you create a new EGL project you can specify a "Base Package" name that is used as the root when "server", "client", and "common" are created for you. Even given this though I personally I don't find this approach very useful since my package structures are always significantly more descriptive and granular than those three general categories.

I would love to see a checkbox or something on the create project wizard so that I could control whether or not these default packages are created.

Also, the "Base Package" doesn't seem to be a project setting...it only applies during initial project creation. If it were a project property it might be more useful so that when creating additional packages I wouldn't have to type the base part of the package name.

--Dan

Re: Getting Started [message #759721 is a reply to message #759654]

Tue, 29 November 2011 13:36

Eclipse User

As for deployment ... maybe I don't understand your question ... but that is still controlled by the deployment descriptor.

The simple case (an EDT project person will surely correct me if I am wrong) is to use a dedicated service that does your database work. Then you can deploy client and server tiers together in a single WAR.

--Dan

Re: Getting Started [message #759739 is a reply to message #759721]

Tue, 29 November 2011 14:30

Eclipse User

The issues are sort of interconnected, Dan. Like you, I want complete control over my package naming. Because I use lots of widgets and subwidgets and such, I end up with dozens of EGL parts and I'd prefer to be able to segregate them as I see fit. But that then raises the question, how does the tool know which packages are to be deployed on the server and which get deployed as JavaScript. Perhaps it does everything for me by inspecting the code and I'm just making things too difficult for myself.

Even if EDT deploys things based on which folder it resides in, if I can extend those three packages, I may still have enough leverage to do what I want.

Re: Getting Started [message #759753 is a reply to message #759739]

Tue, 29 November 2011 15:31

Eclipse User

Ah, so your question is about Java generation vs. JavaScript generation?

You control this with Properties ("EGL Compiler") at the project, package and part level.

By default, "client" is set to JavaScript, "server" to Java, and "common" to both JavaScript and Java. But again, you control this with the "EGL Compiler" properties settings. But there is no magic to using these packages...you can still create your own and set the EGL compiler property according to your own wishes.

--Dan

[Updated on: Tue, 29 November 2011 16:03] by Moderator

Re: Getting Started [message #759755 is a reply to message #759753]

Tue, 29 November 2011 15:37

Eclipse User

VERY nifty. I knew it was coming, just didn't quite understand how. This definitely makes it easy for me to build my projects the way I want. Next is to figure out how to share across projects.

Re: Getting Started [message #759760 is a reply to message #759755]

Tue, 29 November 2011 16:05

Eclipse User

I have an RFE in for RBD to control generation target via annotation. I hate that this crucial aspect of EGL is controlled via build descriptor and project/package/part settings (in RBD) project/package/part properties (in EDT). A code-level annotation would make generation target completely clear and simplify programmer training enormously.

Are you a fan of the properties approach? How would you feel about a code-level annotation to control the generation target?

--Dan

Re: Getting Started [message #759777 is a reply to message #759760]

Tue, 29 November 2011 18:43

Eclipse User

I don't know that I would call myself a "fan" of the properties approach. I see where annotations could be very useful. However, I do have a concern that if annotations were the only method for generation control I would have to annotate every part. I'm not sure I really want to do that, either! Part of the beauty of EGL is that you can write the same code and deploy it to different targets; annotations at the code level breaks that particular paradigm.

That being said, as generation options increase, I suspect that annotation will become more and more attractive, especially if it can be used as an override or addition to properties-level generation control. What do you think?

Re: Getting Started [message #759789 is a reply to message #759777]

Wed, 30 November 2011 00:03

Eclipse User

Personally, I would prefer to annotate each part but my RFE proposes using annotations to augment/override the properties approach.

In my proposal an annotation allows for multiple generation targets. This is important in order to achieve generation to multiple target languages where desired (and to completely retain the multiple-target paradigm that we know and love).

I find that new developers have an extremely difficult time catching on to the properties approach to generation targets (especially as implemented in RBD). I loved the way Chris and Co. made EGL CE smart enough that we didn't have to specify generation targets at all -- it "just knew" -- but I have learned from talking to IBM folks that the approach taken in CE was less than ideal. So I see where some mechanism is required but I would prefer a mechanism more expressive than properties.

Previous Topic:	Changes to the update site
Next Topic:	Java 1.6, Servlet 2.5 and J2EE Preview Server

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 02:32:08 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter