Profile cover photo
Profile photo
Bastian Waidelich
96 followers
96 followers
About
Posts

Post has attachment
Hi all,

this might be a little bit off-topic, but when the subject came up I had to think of a request I received a while ago: Back then a client of mine needed to import a whole lot of product records to a (in this case TYPO3) application but didn't have backend access to the old system.
We decided to kickstart a little command line tool that crawls the website and maps data and resources according to some configuration (see https://github.com/bwaidelich/Suckr/blob/master/Configuration/example.yaml for a simplified example).

In this case the constraints were really limited of course, but it worked surprisingly well. So it might be feasible to try out a similar (obviously more flexible) approach for general website migrations. I could imagine extensible crawlers/parsers that could fetch data via CSS-selectors, semantic web annotations, ... and convert it into a more general format (At first sight CMIS seems an overkill to me, IMO it could be a simple tree structure of some sort).
And then some custom importers could use that as source for creating Content types, page nodes etc. for Drupal, TYPO3, ...

This might sound a little bald and certainly has some drawbacks (it is quite slow and you only get data that can be crawled via HTTP) but IMO it's worth thinking about, given the opportunities this would provide.

Post has attachment
Before you started adding the is_string check in https://github.com/cognifloyd/Cognifire.BuilderFoundation/blob/proof-of-concept/Classes/Cognifire/BuilderFoundation/Blob/BlobQuery.php#L48 you could have written a test "constructorThrowsExceptionIfBlobFilterIsNoString".

If you follow TDD strictly you should even write such test before creating the BlobQuery class at all. Running the test will throw an exception - which means your test is failing. Then you fix it by implementing the class and writing the constructor with the is_string check, run the tests again, enjoy the green bar and write the next test ;)

If your tests get too complex or you end up mocking a lot of dependencies your class probably does too much! For example: I would suggest to leave I/O operations out of BlobQuery completely and work with strings instead.

BTW: I found http://www.objectmentor.com/resources/articles/xpepisode.htm a good read. It's very old and the examples are written in Java but I found it easy to comprehend
Add a comment...
Wait while more posts are being loaded