On Wed, Sep 2, 2009 at 3:12 AM, Benjamin Muskalla <
[email protected]> wrote:

> Hi David,
>
> you should be the one to blog about the first RAP-based application written
> in Scala! Really like the idea ;-)
>

:-)  Thanks!


> Regrading PDE Build: maybe it's enough to trigger the scala compiler in one
> of the build steps yourself (eg. postFetch) and let PDE Build just gather
> all the class files together.
>

Maybe.  I'm seeing a *TON* of momentum behind Maven, so that's what I plan
to try first.

Thanks for the encouragement!


Dave

>
> Regards,
>  Ben
>
> David Orme wrote:
>
>> This is very interesting to me as well, but with Scala on the server side.
>>  I've gotten addicted to the kinds of powerful and readable DSLs you can
>> build so easily in Scala.
>>
>> The main hurdle I'm facing is in regards to how to build this.  PDEBuild
>> doesn't support Scala.  It looks like Maven does, but Maven doesn't target
>> Equinox by default.  Maybe that's not such a big hurdle.  We'll see...
>>
>>
>> Dave Orme
>>
>> On Mon, Aug 31, 2009 at 5:23 AM, Benjamin Muskalla <
>> [email protected] <mailto:[email protected]>> wrote:
>>
>>    Hi Alex,
>>
>>    what you describe is a scenario we follow in the RAP [Rich Ajax
>>    Platform] project. RAP allows you to write application based on the
>>    Eclipse technology stack (OSGi/Equinox, Workbench) and remoting it
>>    to a browser of your choice. I think the diagram on this page
>>    describes best how the architecture of RAP is done:
>>    http://eclipse.org/rap/introduction.php
>>
>>    As e4 is concentrating on being a good platform for multi-user
>>    applications, RAP can now reuse the e4 stuff as-is to write powerful
>>    ajax applications without the need to write the UI in JavaScript/HTML.
>>
>>    Take a look at the second part of the e4 webinar to get some more
>>    insight:
>>    http://live.eclipse.org/node/783
>>
>>    You may also take a look at one of the wiki pages how to run e4 on RAP:
>>    http://wiki.eclipse.org/E4/RAP_Integration/Experimental
>>
>>    One of the biggest advantages of this approach is that you don't
>>    need to reinvent the client-side on your own but can reuse existing
>>    technologies and knowledge. Furthermore with OSGi on the
>>    server-side, you're still able to put in bundles at runtime as you
>>    wish. You can even reuse the JavaScript Bundle support to write your
>>    application if you want.
>>
>>    Hope that matches your idea of "e4 as a killer Ajax platform" ;-)
>>    If there are any open questions, feel free to ask!
>>
>>    Regards,
>>     Ben
>>
>>
>>    Axel Rauschmayer wrote:
>>
>>        I'm currently evaluating client/server solutions for Ajax
>>        applications. Does the following scenario make sense? Will this
>>        be supported in a future E4 version? When?
>>
>>        - Server: OSGi modules written in either Java or JavaScript
>>        - Client: Dojo
>>        - Client-server communication: via JSON-RPC
>>        - Server-side plugins should be able to contribute client-side
>>        modules. How would this be done? One possibility is for the
>>        server-side modules to contribute server-side directories that
>>        are accessible from the client. This kind of server-side file
>>        system contribution would be desirable for static content (HTML,
>>        CSS, images, ...), too.
>>
>>        If all of this worked, it would make E4 a killer Ajax platform.
>>        E4 would be a lightweight alternative to Spring, Aptana Jaxer, etc.
>>
>>        I do realize that this is the SWT/Browser Edition approach
>>        turned inside out, but it would give one excellent modularity
>>        while having more control over the GUI in the browser. Plus,
>>        server-side language agnosticism is also a cool feature.
>>
>>        Axel
>>
>>
>>    _______________________________________________
>>    e4-dev mailing list
>>    [email protected] <mailto:[email protected]>
>>    https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> e4-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to