[TYPO3-mvc] extbase based website online

[Franz Koch]

Hey folks,

finally the project that bugged me for the last 2.5 month is now online 
[1] (german only site for now).

This website is using TemplaVoila (primarily for upcoming stuff), DAM 
and IRRE as well as patched versions of ExtBase svn and FLUID svn.

The content of the website is built to 98% by extbase/fluid, except of 
some TYPO3 pages that are only linked in the footer navigation 
(EUROBAUSTOFF, Impressum) as well as the small teaser boxes on the 
bottom of the start page and below the left navigation menu on subpages 
(those teasers are generated via TS and tt_content for now).

The website is for a hardware store chain (german: Fachhandelskette von 
Bauzentren) and is representing the assortment of those stores. So it's 
like a multi-store capable online-shop without basket and checkout. It's 
the online version of a print product catalog, and in future there will 
be added more and more catalogs you can browse.
The "fun" part here is, that almost every store has a different 
assortment, so for the 250 stores there are 230 versions of the print 
catalog the website has to deal with. And in future there will be added 
several more catalogs.

As you could imagine, it's a quite heavy challenge for a first 
extbase/fluid based extension, especially when one hasn't done much OOP 
stuff yet.



Here are the challenges I had to solve:
--------------------------------------------------------
a) getting used to extbase/fluid
Of course one challenge for me was to get used to how extbase and fluid 
work. Unfortunately there where still some bugs in extbase/fluid with 
IRRE etc. that didn't make it any easier.


b) creating good models
As one requirement for this project was to build a common and neutral 
product/article database that can be used for various future projects, 
it was quite hard for me to find a way dealing with the complex 
requirements for the website while keeping the models themselves as dumb 
as possible. So I had to create a lot of intermediate tables/objects to 
resolve dependencies which didn't ease things up for editors and 
especially not for me.


c) complex dependencies
The biggest challenges in extbase for me where the complex queries 
needed for all the dependencies on this website. As mentioned above, 
every single content depends on the selected store and the 
catalogs/products this store has. So no matter which tiny bit of 
information I liked to display, I first had to resolve various 
dependencies to see if the store actually has that 
catalog/chapter/category/product/information. Due to that fact, most 
times I was not able to use the built in object injection by extbase, as 
this always returned all available objects, not the filtered ones, and 
"post processing" (traversing through objects applying filters) just 
didn't seem to be a good idea performance wise with thousands of products.

So in order to speed things up a bit, I created a reference table in the 
db where some of the more complex relations got cached. But the problem 
with this was, that I was not able to use any of this information in my 
models by default. So f.e. I was not able to read the chapter a product 
is in from the ref-table and set it as property in my product. And due 
to various reasons (customization/modularization) there was no direct 
relation from a product to a specific chapter (it takes 4 queued 
relations to get that information). To avoid yet another useless query I 
patched extbase in a way to map any query result to any available 
property - not only ones defined in TCA. I think that my patch for this 
my now got committed.


d) table joins for complex queries
Creating queries with several join tables is currently quite a challenge 
in extbase. As I ran out of time I cheated in those queries and use 
default TYPO3_DB stuff there and then have extbase map the results to 
objects again using api functions. I know that I could have used 
$query->statement('custom stuff'), but it felt as wrong as using 
TYPO3_DB so I stuck with what I already knew. But I'll change that one 
it's a bit more easy in extbase to create joins.


e) damn DAM
Extbase doesn't support TCA fields of type "group", so I needed to find 
a way to get that working correctly. One workaround was to set 
"foreign_table" in the TCA configuration of DAM related fields, but that 
didn't feel right. So I started implementing group-field support into 
extbase. Patches for this are on forge, but still pending. There where 
also issues with MM_match_fields that where not supported by extbase, so 
I also had to add this features, which has been committed to trunk by now.


f) yet another custom fluid viewHelper
I think the title already says everything ;)


g) Nice looking URLs
In order to get nice looking URLs without hacking extbase too much I had 
to mess with realUrl and some nifty scripts using TYPO3-hooks in a very 
early stage in page rendering, re-injecting the controller getVars that 
got dropped by realurl. Re-injection was neccessary to pass 
cHash-validation again. But once I found the right places in TYPO3 it 
worked like a charm.


h) Different content within the same URLs
Another challenge was the store selector functionality, by which the 
very same URL had to deliver customized _cached_ content based on a 
previously selected store. So again I had to mess with cHash-validation 
and injecting a piVar on the fly, based on a cookie value.

-----------------------------


I think that's it. As this extension is not of much common use, I don't 
think I'll publish it - but if someone's interested in parts of it, just 
drop me a note.

Comments are welcome.


[1] http://www.der-neue-katalog-ist-da.de/
-- 
kind regards,
Franz Koch