I want to create custom content elements. I know how this works basically. But I asking myself, if there is a way to store the configuration data of this elements in a decent database table?
I only know the way to extend the tt_content table and store my data there. But with a bigger amount of elements and fields the tt_content would be become bigger and bigger too. I would like to prevent this.
And just before you ask: I don't want to use FluidTYPO3. ;) I just would like to do it with basic TYPO3 functionality.
Don‘t know if there is a nicer way, but maybe you can create your elements with no field definition but with IRRE and min:1 and max:1 - but this is not really a nice way.
The better way is to reuse the fields given in tt_content as often as possible and only add more fields if really needed.
Maybe you should have a look on EXT:mask and EXT:mask_export - those two are very powerful tools to create custom content elements (EXT:mask) and export them as an own extension (EXT:mask_export) so there is no need for these two extensions in production but only in development.
As you create a content element you will always need to use the database table tt_content. Of course it makes sense to use relations to custom records, e.g. if you create elements like tabs, accordions, ...
What you can do is to reuse existing columns as there are - as you said - a lot of those. So reuse fields like header, bodytext, image, ... Take a look at /sysext/frontend/Configuration/TCA/tt_content.php. The benefits are
a bit smaller table which is most of the time not really relevant to performance
well designed fields including a label whith translations into all languages
You can also reuse a field and its configuration and override it with overrideChildTca. See https://docs.typo3.org/typo3cms/TCAReference/ColumnsConfig/Properties/InlineOverrideChildTCa.html?highlight=overridechildtca in the docs.
I recommend you to have a look at the typo3 extension mask. You can create custom contents and map existing tt_content fields to your new elements. It makes sense to reuse the header, bodytext, media, image fields because the backend preview will adopt automatically.
I used it recently and it works really nice! Here is some resource to jump in (only german)
If you do not need to have indexes on your new fields it is not a big problem to blow up tt_content with new fields. It does not impact the performance so much.
If you need to have new 1:N relations from your content to some child-record (accordion, team-listing, etc), simply add them as inline elements (IRRE) and add the field to your types-string.
If you need to have a new kind of data, that should be filterable, sortable and so on, you should create a new type of record with its own table structure and use extbase plugins to display that data.
As long as you simply need custom contents, you are fine with extending/remapping tt_content.
You can use hooks for this.
In your ext_localconf.php:
$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][] = \Namespace\Hooks\Classname::class;
And in Classes/Hooks/Classname:
<?php
namespace Namespace\Hooks;
use TYPO3\CMS\Core\SingletonInterface;
use TYPO3\CMS\Core\DataHandling\DataHandler;
class Classname implements SingletonInterface {
public function processDatamap_beforeStart(&$dataHandler) {
$datamap = &$dataHandler->datamap;
}
}
Here you have to modify the $datamap to your needs.
Documentation is here: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Typo3CoreEngine/Database/Index.html
Kind regards
It is explained here https://learn-typo3.com/blog/news-detail/how-to-create-custom-content-elements-on-typo3, however I prefer extending and reusing tt_content fields.
Related
I'm working on a project based on Laravel 5.3 and Backpack CRUD. My project has about 8 different content types (news, page, portfolio, events, team, video, gallery, jobs).
I need to be able to add tags to every content type (n-n), and every content type has its own specific tags, so tags are NOT shared between the content types.
If I want to use the select_multiple or select2_multiple field type, I would need 8 tables for the content itself, 8 pivot tables, and 8 tables for the tags(!).
Obviously I would like to have just one table for the tags, but if I use the select_multiple or select2_multiple field type, I get all tags in the edit-form of every content type.
So, my question is: Is there an elegant way to filter the results of the select_multiple or select2_multiple field type?
I have created a simple schema with two content types:
http://dbdesigner.net/designer/schema/60412
In this example I want to be able to filter the tag list on content_type_id, when I'm editing the content of news or page. So I just want to see the news tags in the news-edit form, and just the page tags, in the page-edit form.
Or maybe I should just use the select_multiple field type as intended, and accept the 8 tag tables(?)
Any help or advice would be greatly appreciated.
I think a clean way would be to:
create different models for each tag use, so NewsTag, PageTag, PortfolioTag etc. that would only extend the Tag model and use a global scope to filter the results after content_type_id;
use backpack select2_multiple fields with NewsTag, PageTag, PortfolioTag etc; anything you set on the Tag model will be used (including the table attribute, mutators, accessors, etc);
Cheers!
I have been using the content report table macro, which has been working. Ideally, I only want to list content matching certain labels, and lock in an alphabetical sort order and not show the content author.
I have not been successful in figuring out a way to do this just yet.
Is there a way to just edit the source code for that macro and create a "new one"? I'm struggling to find any useful documentation out there.
Any suggestions are appreciated!
I was also interested on doing this some days ago. Unfortunately, the Content Report Table Macro only have very limited parameters which are very strict. However, the way I succeeded to display only certain properties from the pages and present them in a tabular way (in Confluence 5.8) was with the combination of the macros Page Properties and Page Properties Report, both of them linked by a unique label. I'll break it down below.
Outcome:
1. Set up of properties you want to track
Create a page.
Add the Page Properties macro (no need to specify an ID)
Within the macro just add a table with all the properties you need to keep track of, similar to this:
Important, this is what links the two macros together: Add a label to the recently created page.
2. Display properties in main page
Add Page Properties Report macro. Specify label used across all the already created pages. Also specify the space (I just love this part). In here you also add custom fields (some fields from Content Reports are here). In Options you can specify which properties to display (columns to show), also the sorting order (in my case I'm sorting by the property ID that I added to each page).
Note: if you just want to remove the content author this can even be done easier: no need to add any property, just specify the label of your pages and add the fields you need to show and sorting order.
Hope this helps.
Need: Ability to dynamically build Forms
Structure (simple idea not actual structure)
Admin: Form Assignment, where you create what field you want your new Form to have
FrontEnd: Where the New form will be implemented (this is the root of this question)
FronEnd Storage: When the New form is filled out the data points are written to a set of tables
The idea is simple enough, Go into Admin, select the fields, fieldType, and Labels you want
I.E.
Field Name:*Enter a specific field name, like f_name or email
FieldType: [Text, TextArea, Password, Radio, DatePicker, CheckBox, Select, etc]
Label: What to display on the resulting form, f_name = First Name, etc
Then I hit a page on the FrontEnd where the New form is generated, I fill it out and voila the data is stored in the FrontEnd Storage tables.
So the question is, idea's on how to accomplish this, I already have the Admin section done, it's dynamically building and appropriately binding a frontEnd From that I would like advice on.
Currently my idea is to simply make a shell form that is a huge ugly switch statement that builds sfForm elements and appropriate validators for each field (fields given from what was entered in the Admin area)
I feel this is the 'wrong' way to do it, I did find a plugin 'spyFormBuilderInterface2Plugin' which is old and build for propel not doctrine, but this is the basic idea of what I am after. So how would YOU do it?
Please note I am not looking to Dynamically ADD forms to a current form, I can already do this and it's exactly what is implemented in my Admin section, I need to take data a create a whole NEW form programatically
I've created something like you described, just the way you said.
I have a model FormDefinition which defines a form, and has a collection of FormFields. Each form field has a widget_class, widget_options, validator_class and validator_options.
I have a custom myForm which needs a FormDefinition in it's constructor. In the setup() of myForm, I loop through all fields a instantiate the widgets and validators.
Beacuse in our solution, we needed/wanted to store all form data in separate tabels. My myForm extends from sfDoctrineForm, and my backend has some logic which creates/updates the (php) model and database definition, by just calling the appropriate Doctrine methods. But you could also create an EAV store.
I have a large table which inserts data into the database. The problem is when the user edits the table I have to:
run the query
use lots of lines like value="<cfoutput>getData.firstname#</cfoutput> in the input boxes.
Is there a way to bind the form input boxes to the database via a cfc or cfm file?
Many Thanks,
R
Query objects include the columnList, which is a comma-delimited list of returned columns.
If security and readability aren't an issue, you can always loop over this. However, it basically removes your opportunity to do things like locking certain columns, reduces your ability to do any validation, and means you either just label the form boxes with the column names or you find a way to store labels for each column.
You can then do an insert/update/whatever with them.
I don't recommend this, as it would be nearly impossible to secure, but it might get you where you are going.
If you are using CF 9 you can use the ORM (Object Relation Management) functionality (via CFCs)
as described in this online chapter
https://www.packtpub.com/sites/default/files/0249-chapter-4-ORM-Database-Interaction.pdf
(starting on page 6 of the pdf)
Take a look at <cfgrid>, it will be the easiest if you're editing table and it can fire 1 update per row.
For security against XSS, you should use <input value="#xmlFormat(getData.firstname)#">, minimize # of <cfoutput> tags. XmlFormat() not needed if you use <cfinput>.
If you are looking for an easy way to not have to specify all the column names in the insert query cfinsert will try to map all the form names you submit to the database column names.
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c78.html
This is indeed a very good question. I have no doubt that the answers given so far are helpful. I was faced with the same problem, only my table does not have that many fields though.
Per the docs EntityNew() the syntax shows that you can include the data when instantiating the object:
artistObj = entityNew("Artists",{FirstName="Tom",LastName="Ron"});
instead of having to instantiate and then add the data field by field. In my case all I had to do is:
artistObj = entityNew( "Artists", FORM );
EntitySave( artistObj );
ORMFlush();
NOTE
It does appear from your question that you may be running insert or update queries. When using ORM you do not need to do that. But I may be mistaken.
I am writing code that generates both PDF and RTF documents, depending on the user's selection. The information in both documents is the same.
Until now, we were using classes like Table, Cell, HeaderFooter, etc., which are rendered into the correct form by the documentwriter (either PdfWriter or RtfWriter2).
However, the further I get into trying to make changes (mostly because the upgrade to iText 2.1 left the spacing a little quirky), the more I'm being told to "use PdfpTable", or "Use pageEvents to set headers". It seems like a lot of the generic classes are being deprecated.
I am thinking of revamping the code to separate out the table creations for PDF and RTF. However, all the iText tutorial stuff seems to actually recommend using Table in an instance where both PDF and RTF documents are needed.
Additionally, it appears that while there is a PdfpTable class, there is nothing similar for RTF, so I would be using Table anyway, which would leave me vulnerable to all the quirks that come along with the now unsupported Table class.
Basically, what are the benefits/downsides of separating the code into two sections -- one to create PDF documents, and one to create the same documents in an RTF format, if that was selected? And where does SimpleTable come in to all of this? Will it give me the flexibility that I need?
Thanks!
From the book iText In Action, end of chapter 6:
If you look at the iText API, you’ll also find some other table classes. com.lowagie.text.Table is the original table class; it dates from the early iText days. It uses class com.lowagie.text.pdf.PdfTable internally to render a table to PDF (don’t confuse this class with PdfPTable).
There’s also the newer SimpleTable class, which tries to form a link between
PdfPTable and Table. It’s able to translate itself to a PdfPTable if you add it to a
document that writes PDF or to a Table if you’re producing HTML or RTF. [...]
The major disadvantage of the Table class is that it’s no longer supported. Different
people have fixed most of the known issues, but today not a single person
understands if and how all the Table-methods work. If you decide to use this class,
you’re more or less on your own, and you’ll encounter lots of quirky layout issues
based on historical design decisions. However, this doesn’t mean you can’t make
good use of the Table class.
Advantages of the Table class
With the Table class, you can generate a table structure that can be rendered in
PDF, RTF, and HTML. If you compare the results, you’ll see there are small differences
in the way the table is rendered. This is normal; not every table feature is
supported in every document format.
You can generate a table in PDF, HTML, or RTF using the same code.
You can set padding and spacing the way it’s done in HTML.
You can use the row span without having to resort to nested table.
You can change the number of columns even after you’ve added cells.
You can add cells at specific positions (the number of rows is augmented
dynamically).
You can delete a column before adding the table to the document.
You can let iText add the Table as if it was a PdfPTable.
You get a PdfPTable object based on the Table object.
As opposed to PdfPTable, you can add cells to a Table in a random order, and add
or delete columns if needed. You can even translate a Table to a PdfPTable if you
didn’t use setRowspan().
There’s also the SimpleTable, class, which is a simplified version of (PdfP)-Table. When adding a SimpleTable to a PDF document, iText first attempts to add
the table as a PdfPTable; if this fails, it’s added as a Table. When adding a SimpleTable to an RTF or HTML document, it’s added as a Table. SimpleTable differs
from the Table and PdfPTable in the sense that it reintroduces the concept of rows.
This can be handy if you’re parsing an XML file that has a table-row-cell structure.
If the tag corresponding with the rows has attributes, you don’t have to define this
property for each cell in the row separately; you can set the property for the entire
row at once.
Summary
PdfPTable should be your first choice; but depending on the requirements defined for your project, there can be good reasons to opt for Table or SimpleTable.