Call to undefined method FOF30\View\DataView\Html::getRenderedForm()

[miguel-navegabem]

Looks like after the new Akeeba Backup update which includes a new FOF30 version this method doesn't exist anymore.

FOF3 Version 3.6.1 (was working in previous versions).

What's the alternative way of rendering the XML layout inside the php blade view?

Thanks.

[nikosdion]

FOF Forms were deprecated in FOF 3.4 and removed in FOF 3.7.

There was no other way to do it. The implementation was very much tied to the HTML output of Joomla. With Joomla 4 using BS4 and Joomla 3 in BS2 there was simply no viable way to keep maintaining FOF Forms.

[Skullbock]

Hi @nikosdion sorry to jump in.

Can i maybe suggest to leave forms there, and specifying that they work just on 3.x? That way, the current extensions keep working on 3.x sites, and when we need to upgrade to 4.x, we switch to blade?

Just my 2 cents ;)

[miguel-navegabem]

Hi @nikosdion sorry to jump in.

Can i maybe suggest to leave forms there, and specifying that they work just on 3.x? That way, the current extensions keep working on 3.x sites, and when we need to upgrade to 4.x, we switch to blade?

Just my 2 cents ;)

Thats what i was hoping to happen... the problem is that if someone updates Akeeba Backup for example, other extensions might stop working because it updates the framework.

XML forms are very handy and they can keep up with the framework progress without messing around with PHP or making the extensions to stop working because of discontinued/deprecated code.

[nikosdion]

Forms were bolted on FOF 2 under the promise there'd be core support for read-only form fields. Not only this never happened, the Joomla project screwed me over and I almost lost my livelihood since they were not letting me update my software.

Why did I add Forms in FOF 3? Well, the work had already began and I was already using Forms in my software. Replacing them with PHP view templates would only make sense if I had a stable CSS framework since at this point it was painfully clear that BS2 was dead as a dodo.

I'm sorry that I believed Joomla's lies and bothered with Forms anyway. It would have made sense for a RAD framework but Joomla made it clear that they don't want one. And I sure as hell don't want to maintain my own fields library -- it's a fool's errand.

If anything, Joomla 4 made it abundantly clear that the haphazard way I had bolted Forms on FOF was unmaintainable. Not only it's using BS4, it allows form field layouts to be overridden per template, frontend and backend. Even basic fields, like text fields. If you don't understand how that completely breaks Forms and why it can't be maintained I have nothing to say to you other than RTFC (Read The Fucking Code).

Meanwhile, keeping the Forms package I no longer use for the past few years literally costs me money. Forms add 200KB to the installation package of each and every extension I publish. This might not sound a lot to you until you realise that people download our software packages from our CDN a few million times a year.

And no, I cannot keep it as an optional add-on. FOF Forms were deeply integrated into the framework in several places. It was the Factory, the Model, the Controller, the View etc. You can't easily refactor that. You need to rewrite FOF from scratch.

So why not rewrite FOF? For the same reason that I didn't call this release FOF 4. Joomla 4 moved to a direction that makes most of FOF unnecessary. There's no point wasting time in architecturing a new framework and going through the pain of rewriting all extensions when Joomla 4 finally overcame its ambivalence towards MVC and ships with a truly decent MVC framework. If anything, future versions of my software will be rewritten to use Joomla 4 core (a requirement for using the Joomla API and CLI applications) and FOF 4 will be a far smaller library of things you can bolt on to make your life easier. Spending time to even rename FOF3 to FOF4 in my code had a negative value proposal, more so when there are exactly TWO people in the world that use FOF Forms and I'm talking to them right now.

In any case, you can simply fork FOF 3.6 as long as you use a different package name and namespace which does not use the words Akeeba and FOF in it. You can use Rector to convert your extensions from one framework to the other with minimal work (it can rename class uses very easily indeed). Your immediate problem is solved but do bear in mind that your extensions have an expiration date of end 2022 when J3 goes away. You still need to do the work.

[Skullbock]

Hi nick, thanks for the reasoning. I was of course in the process of removing the forms, but i expected FOF to remove the forms package in v4, following semver, that's why i wasn't expecting a simple update of akeeba to break everything down.

Anyway i managed to revert fof to a previous version and it works, and i'm now in the process of rewriting my views. Fortunately i've already done most blade boilerplate code already.

Thanks