[TYPO3-mvc] extbase based website online

[Thomas "Thasmo" Deinhamer]

Well done, sounds impressive!
Looking forward seeing your patches
and improvements merged into Extbase and Fluid.

Also the realurl adjustments look great!

Thomas

Am 09.03.2010 16:48, schrieb 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/