Skip to main content

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

Hello Boris!

Thank you for your quick reply!


Le Fri, 27 May 2011 02:17:10 +0300, Boris Bokowski <Boris_Bokowski@xxxxxxxxxx> a écrit:

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.

Indeed. This needs some experimentation.

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.

Thank you! That is sufficiently clear.


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.

Thank you! We hope that refactoring the code will not be needed.


- 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.

After further investigation it looks like the js-tests folder holds one performance test and a test model. We can run the perf test from the sample page. Does this mean that the editor does not have unit tests yet, for testing regressions? Is the performance test only for sample purposes? Does the Orion client project have unit tests that exercise the editor API?

Additional concerns from looking into the sample source code:

- There is a script samples/styler.js that holds rules for highlighting Java, JavaScript and CSS. These do not seem to be part of the Orion editor component - the code is just a sample?

- What are the plans for syntax highlighters?

- Similarly, I would like to know the plans about samples/rulers.js and undoStack.js.

I am interested to know about these scripts because I am looking into picking which scripts I need for our devtools. These seem to be basic features that we would like to be part of the editor component (either in editor.js or in separate files that we can bundle). Given they are inside the samples folder, does it mean we cannot rely on them?

Having also looked into orion.client.core I have questions about:

- What are the orion.client.core/static/examples/ pages? Are these just different samples on how to use the editor?

- What is the relation between orion.client.core/static/js/styler/ scripts (textMateStyler.js and htmlSyntaxHighlight.js) and orion.client.editor/web/samples/styler.js? We will need JavaScript, CSS, HTML and perhaps more highlighters.

- I see in orion.client.core/static/js a few scripts that seem to be part of (or additions to) the editor component: editorCommands.js, editorFeatures.js, editorContainer.js, search*.js, selection.js, syntaxchecker.js and jslint*.js. Are these script that might be of potential interest for us? Or they are script that are only useful in the context of the Orion client IDE?

If some of the scripts in orion.client.core are relevant to the editor component, as a standalone component, we would like them to be bundled as such - we would like the core editor to be available for packaging and re-use with all of the highlighters and features (line numbers, undo stack, and so on). For our purposes we would select the relevant highlighters and features, but having them in a single place makes things much more straightforward.


- 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

Thanks!

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.

Agreed.


Thank you for your answers!


Best regards,
Mihai


--
Mihai Sucan
http://www.robodesign.ro


Back to the top