Talk:ECT
From TYPO3Wiki
Contents |
General remark on the mission statement
The mission statement is somehow irritating to me: "We badly need a core team for the coordination of frontend extension development. This field is neglegted since long because everything is still focused on BE-development."
Do you really want to limit this team's task to FE extensions only? I think this is no good idea because this would by consequence make it necessary to have another team doing coordination work for BE extensions (i.e. modules) only. The statement also implies that we already had an extension coordination effort in BE extensions. That is only (partly) true even for the TYPO3 core - and clearly not true for all other BE extensions apart from the core. In my eyes, they also need coordination to make interoperability make come true. Besides: the distinction between FE and BE is in itself a bit inconsistent, so that especially newbies will have even more difficulties in finding the right solution for their problem.
If you really would like to keep up with the aforementioned mission statement, you should change the team's name to FECT (the FE Extension coordination team), just to let people know what they may expect from this team and what not.
But if you want to continue the "old" reviewing process this let's no other option than to alter the mission statement accordingly.
--Clonedyke 12:08, 9 Dec 2005 (CET)
Answer to: General remark on the mission statement
I simply copied my original posting in the newsgroup here. The target has meanwhile extended to extensions more generally. Most bigger extensions are a mixture of FE and BE. That categories don't really work.
--Elmar 12:13, 9 Dec 2005 (CET)
Glad to see that you agree on that and thanks for the clarification of the mission statement.
--Clonedyke 12:39, 9 Dec 2005 (CET)
Global Extension Naming Scheme
In the course of building the Quickstart Packages and/or by programming new EXTs we could build up a "global extension naming scheme" like ect_*
...what do you think?
Best!
--Arnd 14:12, 11 Dec 2005 (CET)
Hello Arnd,
this idea is good, but what is with names from existing extension that will be included without any changes. Then you must rename the extension on every update, like rtehtmlarea in ect_rtehtmlarea.
... and what do you think?
Greets Manfred
--Manfred 08:15, 12 Dec 2005 (CET)
Hi Manfred,
maybe this was not clear enough =;o)´
Renaming existing extensions makes no sense, of course! I mentioned this in order to propose a naming system for the new extensions programmed by this team.
A ect_* extension could stand for good quality and good documentation.
Best!
--Arnd 11:21, 12 Dec 2005 (CET)
Hello Arnd,
ok, i have understood your plan! Now i like the sound of your plan. I agree with that, the idea is good :)Thank you for your replay.
Best wishes Manfred 11:47, 12 Dec 2005 (CET)
Real URL compatibility Chart
In the article, i've added for Projects the mjseventpro. Arnd means, that is not compatible with Real URL extension. I think that we need at this time a Real URL compatibily Chart List. Any helpful suggestions?
Greets Manfred
Definition of the term "Portal Standards" in relation to TYPO3
I think it would be wise to define the term "Portal Standards" as a first step just to make sure everybody thinks in the right direction when planing next steps.
rainer
--Clonedyke 16:08, 12 Dec 2005 (CET)
It is a term even Kasper uses. Maybe we should ask him first for definition of it.
--Elmar 08:33, 13 Dec 2005 (CET)
Hi there, I came a little late for the discussion on the dev-list. I posted these thoughts:
A little about my specific views on what a portal standard could be for frontend extensions:
- Same templating principle applies to all extensions [Probably they all use a template engine which in turn makes various types such as marker based, TemplaVoila, Smarty, hardcoded and TypoScript available based on preference.]
- Same CSS principles used for all default output to ensure quick deployment that fits website style out-of-the-box
- Same configuration principles in backend (FlexForms seems popolar now-a-days, probably very little TypoScript needed)
- Same style manuals and guarantee of a good manual
- Developed with other extensions in mind within the "family" adhering to the portal standard; means provides APIs to itselfs and supports APIs from other extensions (interoperability).
--Kasper 22:18, 14 Dec 2005 (CET)
http://portals.apache.org/jetspeed-2/ http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/index.html this might serve as inspiration...
Within TYPO3 I expect it to be soemthing around:
- user management
- page handling
- contenthandling
- TypoScript-Setup for FE-Output
- TSConfig for Forms
- Flexforms-XML
...TOBeDiscussed
--PeterN 22:05, 30 Jan 2006 (CET)
ECT wiki structure
The main page is getting really long. I would split at least the "extension analysis" to a new page.
--Stefano 11:39, 15 Dec 2005 (CET)
Simply do it, if you feel it's time to move something out. We still can revert it, if necessary. --Elmar 15:56, 15 Dec 2005 (CET)
New stuff for your team
Hi ECT! I added some stuff what will help you.
- Two aliases for your team-startpage now exist: Ect and ECT. So the short external link is http://wiki.typo3.org/index.php/ECT
- The page Compatible Licenses is nearly ready now. Please tell me if you see something is missing.
--Daniel Brüßler 14:07, 16 September 2006 (CEST)
About Grouped List Layout
Please, report your opinions. I will release a new extension, SICI Dam Downloadlist , that uses that approach.
If this you are interested, sici_core standalone extension , will be released.
--Davide Principi (dabba) 11:03, 30 January 2006 (CET)
