[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Orion editor development and integration

Hello Mihai,

Thanks for considering to use the Orion editor in the Mozilla codebase! See below for my answers:

Mihai Sucan wrote on 2011/05/26 20:23:41:
>
> The editor needs to meet the requirement of running in a different
> environment/context than that of a pure web page. This means that the
> editor source code needs to cope with XUL documents where, for example, we
> have no document.body, or where we have the requirement that
> createElementNS(XHTMLNS, "foo") is used (this is because the default
> namespace is the XUL namespace, and for any new HTML element added the
> editor needs to provide the XHTML namespace). We will try to keep code
> changes as minimal as possible - for example, we might be able to avoid
> the problems mentioned by putting the editor inside an iframe.


This sounds doable. Note that the editor uses a (same-domain) iframe already - this is being done so that the text selection won't escape the editor area, and potentially there are other reasons that Silenio and/or Felipe could comment on. Not sure what happens if you nest this iframe one more level.

> Setting the technical details aside, we will look into the integration
> work needed to be done, and we would like to know what is the best way for
> us to contribute changes back to the Orion project? Inevitably we will
> have to make changes to the code editor to fit our use-cases, within the
> contexts where we would like to use it. We would like to keep clear from
> maintaining a fork of our own for the Orion editor, hence code
> contributions upstream make sense.


Cool! The current process for contributing (and on our side receiving) code contributions for Eclipse projects using Git is explained here: http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions. As you can see, the policy is that each contribution needs an associated bug in our Bugzilla. The patch itself can be made in form of a pull request, or as a patch on the bug, whatever is easier for you.

Be aware that patches changing more than 250 lines of code are subject to an additional IP review step. This is nothing to be afraid of, but may result in a slight delay before we can merge such contributions.

> From:
>
> http://wiki.eclipse.org/Orion/Getting_the_source
>
> It looks like the suggested approach is to get the Orion client and server
> code, and use Eclipse for development.
>
> Some of our concerns:
>
> - Is it possible to just do development work on the editor, without having
> to go knee-deep into the development work-flow of the Orion client and
> server? By the looks of things, yes, it's possible. As simple as one does
> embed the Orion editor in a web page, one can also make changes to the
> code and ... test them.


This should be fine. The code that is currently called editor.js (and its dependencies) is fairly low-level, and does not include some of the common editor features. We are certainly open to refactoring our code as to make it easier for you to consume it at the level that makes the most sense for you.

> Reading through the architecture overview of the project it would seem
> that indeed Orion's components are loosely coupled, sufficiently
> independent of each other.
>
> ( http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Architecture
> )


I hope so! ;-)

> - Still, that seems to entail making changes that fit our needs without
> any regression testing. The orion.editor folder includes the js-tests
> folder which holds two _javascript_-based tests. Where is the documentation
> on running these tests?


I don't know off the top of my head (and am travelling this week). I hope that someone else from the Orion team can answer this.

> - The Orion editor component is used by the Orion client. Our changes
> should not introduce regressions into the wider project. Do the
> editor-only tests suffice? From our perspective we should not directly
> worry about these matters - since the editor tests should deal with this.
> If there's a regression that's later caught, then the editor will/should
> have a new test added by the one who fixes the bug.


I agree, this makes sense.

> - Does the github mirror represent the latest Orion editor snapshot? Is
> this a repo of a "stable" codebase? Are there any different repos with
> other work that's being done, that might be of interest to us?


The GitHub mirror is updated from the master repository at git.eclipse.org once a day but apart from that contains the latest code. It's up to you which one you'd rather work with. See also: http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/

> - Do you accept pull requests on github? Or how shall we proceed when we
> want a change in the code? Obviously pull requests and specific changes
> will be discussed at their own times, and changes will be made such that
> they fit both with our needs and the overall upstream project.


Like I wrote above, you should be filing items in our Bugzilla instance. Here's a Bugzilla template link you can use: http://tinyurl.com/3pfmctc

> Or is there a different process to submitting changes from external
> contributors?
>
> - Are there any coding guidelines? To make sure we don't submit pull
> requests with obvious mistakes.
>
> ( beyond those at http://wiki.eclipse.org/Orion/Coding_conventions )


Nothing comes to mind, but I suggest that you try out the process with smaller contributions first so that we can all learn how best to collaborate.

Thanks for asking, we are looking forward to working with you!


Boris