[MAGNOLIA-985] cleanup of import methods in DataTransporter (and depending classes) as preliminary work for new XSL transformation feature Created: 24/Jul/06  Updated: 23/Jan/13  Resolved: 05/Sep/06

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.0 RC3
Fix Version/s: 3.0 RC3

Type: Improvement Priority: Minor
Reporter: Oliver Lietz Assignee: Philipp Bärfuss
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File Bootstrapper.diff     File Bootstrapper.diff     File DataTransporter.diff     File DataTransporter.diff     Text File DataTransporter.java     Text File DataTransporter.java     File ImportPage.diff     File ModuleUtil.diff     File pom.diff    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Renamed methods, made them more consistent and improved javadoc. This is preliminary work for a new XSL transformation feature. The methods for XSL transformation are also in "DataTransporter" namely "transformXmlStream" and "getXslStreamForXmlFile".
The "importXmlStream" method (was "executeImport") is somewhat inconsistent and should be reviewed by the core developers. The two filters "ImportXmlRootFilter" and "MagnoliaV2Filter" for the XML stream are only applied when "keepVersionHistory" ist not true, otherwise the XML stream is completely unfilterred.
The XSL transformation should happen after all filters are applied. This could be useful when bootstrapping and default values should be changed (passwords, subscribers, ...). It makes more sense to save a XSL file to version control, because it is easier to read and self-explanatory than an exported system view of the repository. Maybe a plugin mechanism for filters and transformations makes sense here.



 Comments   
Comment by Oliver Lietz [ 24/Jul/06 ]

One new dependency for XSL transformation:

CircularByteBuffer from com.Ostermiller.util.*

http://ostermiller.org/utils/CircularBuffer.html
http://ostermiller.org/convert_java_outputstream_inputstream.html

license: GNU General Public License

Comment by Nicolas Modrzyk [ 25/Jul/06 ]

you can't introduce code that is under the GPL license into Magnolia. This is a copyright breached since Magnolia is LGPL.

Comment by Oliver Lietz [ 29/Jul/06 ]

Had the license issue in mind, but couldn't find anything on the website and the wiki. Therefore I named the license explicitly.
Found a far smarter way of adding the XSL transformation feature with filter chaining. There's no need for the CircularByteBuffer and Ostermiller's lib anymore, the pom.diff can be dropped.
This is my first working version of the new XSL transformation feature.

Comment by Oliver Lietz [ 01/Aug/06 ]

updated diff against revision 5692

Comment by Philipp Bracher [ 05/Sep/06 ]

I dicided to use properties files instead of the xsl mechanism. I think it is much handier.

Generated at Mon Feb 12 03:22:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.