Bugzilla – Full Text Bug Listing
| Summary: | [Dawn] Provide web-based access to GMF Diagrams | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Martin Fluegge <martin.fluegge> |
| Component: | cdo.dawn | Assignee: | Martin Fluegge <martin.fluegge> |
| Status: | NEW --- | QA Contact: | Eike Stepper <stepper> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | lu.xingxiao, milesparker, saurav.sarkar1 |
| Version: | 4.13 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | Appealing to a Broader Community | ||
|
Description
Martin Fluegge
(In reply to comment #0) > Dawn should provide web-based access to GMF diagram as shown in the screencast > (in the end). > http://www.mftech.org/dawn/screencasts/8_more_sophisticated_Diagrams/8_more_sophisticated_Diagrams.htm > This certainly also means to extend the generator to provide an easy generation > for the web-based extension. It should be interesting.How are you planning for web based editing. Are you intending to you use RAP as an underlying technology ? Saurav, the old implementation used Open-jACOB (http://www.openjacob.org/) a Java Script implementation. Basically the server site acted as controller which combined the data stored in the repository (semantic/notational) with a JS based implementation. The editing was implemented be AJAX call-backs. The old proof of concept was quite prototypically as you could see in the Screencast. Unfortunately the framework is not free anymore so I am going to implement the whole stuff form the scratch. I am not aware of a GEF based web implementation on RAP. But I might be wrong. If not I fear that for the diagram pane itself something new has to be implemented. For the other parts (Explorer, Toolbar, etc.) I planned to have a closer look at RAP. But actually my plan is to have a framework independent renderer component. So RAP might be just one the frameworks used. (In reply to comment #2) > Saurav, > the old implementation used Open-jACOB (http://www.openjacob.org/) a Java > Script implementation. Basically the server site acted as controller which > combined the data stored in the repository (semantic/notational) with a JS > based implementation. The editing was implemented be AJAX call-backs. The old > proof of concept was quite prototypically as you could see in the Screencast. > Unfortunately the framework is not free anymore so I am going to implement the > whole stuff form the scratch. > I am not aware of a GEF based web implementation on RAP. But I might be wrong. > If not I fear that for the diagram pane itself something new has to be > implemented. For the other parts (Explorer, Toolbar, etc.) I planned to have a > closer look at RAP. But actually my plan is to have a framework independent > renderer component. So RAP might be just one the frameworks used. Hi Martin, RAP with this Helios release does provide GC support which provides some basic drawing capabilities on canvas. Regards, Saurav Hi Saurav, I heard that the GC is now available on RAP. Unfortunately, due to my always limited time I was not able to look at it now. But I'll have a look at it as soon as I start working on this bugzilla more intensively. Thank for pointing me to this :) Cheers, Martin (In reply to comment #4) > Hi Saurav, > > I heard that the GC is now available on RAP. Unfortunately, due to my always > limited time I was not able to look at it now. But I'll have a look at it as > soon as I start working on this bugzilla more intensively. Martin, I'm also looking at solutions for graph based representation -- in my case I'd like to figure out how to support Zest (lite?) API on browser.. This is not at all an easy nut..there is a real dearth of graph components for the web for good reason I'd think.. People who have implemented commercial libraries report that performance issues can be a real killer. This is definitely a case where you need to push graphics processing to the server because there is simply too much latency to get acceptable response time otherwise. When you do begin work on this perhaps it makes sense to open a dependent bug for just the generic diagram editing support for this? I'll try to keep you updated on what I discover on my end. Hi Miles, I recently commit the basic start to CVS. You could have a look at the Incubator of the CDO project. I already started to bring up editing support for the web based editors. The API I am going to design will be flexible enough the support different frameworks. Currently I started with OpenJacob's Draw2D. But this might change in the future. I have not tested the performance for this framework yet. But it is definitvely a quite important feature. I would appreciate any information which could support us with this issue. If you find any new framework just drop a note :) Changed FigureParser implementation. Removed dom4j dependencies and use only JRE native classes. Committed revision 7020 Committed revision 33: - trunk/Dawn/features/org.mftech.dawn.dependencies.external.feature Committed revision 35: - trunk/Dawn/features/org.mftech.dawn.dependencies.external.feature Please ignore the last two commit statements. Those were automatically added by accident. Sorry. Moving all open enhancement requests to 4.1 Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Moving all outstanding enhancements to 4.3 Moving all open enhancement requests to 4.4 Moving all open enhancement requests to 4.4 Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |