[TYPO3-ect] Eclipse Plugin Development

Martin Ficzel martin.ficzel at gmx.de
Thu Apr 19 15:07:33 CEST 2007


Andreas Tschirpke schrieb:
> Hello,
> 
> for my master thesis I'm evaluating the feasibility of a
> TypoScript-Editor Plug-In for Eclipse, similar to the existing jeditvfs
> implementation. Is there an interest for such a Plug-In? Perhaps even
> some kind of sponsorship? Or is someone already working on a similar
> project?

> 
> Andreas

i like that idea, just some days ago i posted a proposal for a typo3 rpc
interface to the dev list. i wanted to know weather this makes sense and
is worth the effort.

i personally thought about the option to use flash editors in be-modules
 but a generalized rpc interface would make also your proposed eclipse
intergation possible. since i'm usually working with eclipse it would be
great to use it for managing typo3 too.

>> As Eclipse 3.2 includes a virtual file system it should be possible to
>> create a TypoScript view which could work directly on the server
>> communication via web services or RPC.

i already thought about how this could be done since it's not that easy
to map the typo3 records to a filesystem.

i would suggest a virtual file and folder structure like this.

records/page_1/page_2/main[123].ts_template // a ts-template
records/page_1/page _2/content[123].tt_content // a content record
records/page_1[123].page // a page record
files/content.css // a file in the fieladmin folder

such a filestructure could be exposed in any rpc manner but i would
suggest to use webDav because that would be useful for other tools
aswell. a litte problem is the dualistic nature of pages because they
are records and folders.

the fields inside of the records could be mapped into an xml-structure
and can be connected with xml-schemes.

<ts_template>
	<title>foo</title>
	<constants></constants>
	<setup><![CDATA[
# some typoscript
	]]></setup>
</ts_template>


how can this be implemented in the typo3 backend?

i suggest to write a generic rpc class wich handles the all the record
operations. this class can be used by any others to expose this
interface via XMLRPC / WebDAV /SOAP to the world.

in the core there are already a lot of record-manipulation methods wich
can be used for this interface.

class tx_rpc_base {

	login(){}  // new method maybe the cli-login can be used
	logout(){}

	/*----- page methods ----- */

	getPageInfo( pid );             // new method
	getPageRecords( pid , table );  // new method
	getPageRSP( pid );              // new method
	getPageTypes( pid );            // new method

	/* ---- manipulation of records ----- */
	
	getRecord( uid )              // new method
	setRecord( uid, record )      // use method in tce_main
	moveRecord( uid , pid , pos ) // use method in tce_main
	deleteRecord( uid )           // use method in tce_main
	versionizeRecord( uid )       // use method in tce_main
	localizeRecord( uid )         // use method in tce_main

}

the concrete rpc-implementations can be created like any other be-module.

the most critical part is to enshure that the user/group/page/field
rights are processed correctly. that is only important for the reading
new methods since the existing tce-main functions already handle the
rights for the record manipulation methods.

>> Is there already any idea how the TS implementation in TYPO3 5.0 will
>> look like? Would be a shame to render this project useless in the "near"
>> future :)

i think ts will not change that much and i dont think that this work (if
done) will be obsolete in the near future. if the eclipse plugin is
based on a generic rpc-interface it will be no problem to support that
interface in 5.0 too.

>> Hope to get some feedback.

i'm currently thinking about creating the rpc-base class and an xmlrpc
interface. like you i want to share my ideas get some feedback.
especially i would like to discuss the rpc_base interface because this
interface will be hard to cange if other code is relying on it.

i think the best way to start would be a wiki page wich is explaining
the concepts. maybe we could do some of the work together or at least
avoid double work.

regards Marin Ficzel


More information about the TYPO3-team-extension-coordination mailing list