I'm developing an extension for TYPO3 8.7 that queries an API for some data.
The frontend part works, although the API is called live at the moment.
Now I'd like to build a little backend module in which the integrator can at least manage the API credentials. Maybe also storage PIDs and other settings.
I guess storing data like these is usually done using TypoScript(?), but it would be nice to have a interface for storing settings of all kinds.
I rather guess I could create a database table and access it in the backend and frontend on a low level.
But before I do so I'd like to ensure that there is no other, designated way to do so. Maybe interact with the settings array somehow or whatnot.
I thought that storing configuration data would be a common usecase for backend modules. But I could not find any example for this.
Am I mislead about the usage of backend modules somehow?
TYPO3 Provides a Lot of Configuration Options.
in the Extension Manager
this allows you to set settings on a Systemwide Basis.
allows you to Set extension settings. using the ext_conf_template.txt this is easy for extension developers. and only accessible by admins. https://docs.typo3.org/typo3cms/CoreApiReference/ExtensionArchitecture/ConfigurationOptions/Index.html
Typoscrip Contants
this allows you to set configuration on a page basis, this is a great choice if you setup different settings on diffrent pages. or have a mutlipe sites in one TYPO3 Installation. there is an Interface "Constants Editor" in the Template Module which allows editors to set the settings of the constants.
Plugin / Flexform
the most common way an editor configures some settings. but they have to repeat them for every plugin.
Backend Modules
Backend modules are Designed for mor Complex task like manageing a News workflow. or giving inside-view into some process (status reports etc.) of cours they could be used to just store some simple settings. but its uncommen. and clutters the TYPO3 Backend Interface.
AdditionalConfiguration.php / ext_localconf.php this allows you to set very Low Level Configuration. if your configuration needs to be Availible only to Developer or needs to be Present in an Eary Bootstrapping Phase of TYPO3 this is a good choice
I your case, I would create a simple backend module and store the credentials in the Registry. This is easy to explain to the customer and you have the possibility to give access to that module to special user groups. By using the registry there's no need to create custom Tables.
Guide on how to create a backend module : https://docs.typo3.org/typo3cms/ExtbaseFluidBook/10-Outlook/2-Backend-modules.html
Guide on the Registry: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/SystemRegistry/Index.html
Related
I've looked around the site to see if there are any people who have changed the CKAN API interface so that instead of uploading documents and databases, they can directly type onto the site, but I haven't found any use cases.
Currently, we have a page where people upload data sets through excel forms that they've filled out, but we want to make it a bit more user friendly by changing the API so that they can fill out a form on the page rather than downloading the template, filling it out and then uploading it.
Does CKAN have the ability to support this? If so, are there any examples or use cases of websites that have use forms rather than uploads?
This is certainly possible.
I'm not aware of any existing extensions that provide that functionality, but you can check the official list of CKAN extensions if there's anything that fulfills your needs.
If there is no existing extension that suits you then you could write your own, see the extension guide for details on how to do that.
Adding an API function to CKAN's API is possible, but probably not what you want in this case: the web UI usually does not interact with CKAN via the API but via Flask/Pylons controllers. Hence, you would add your add controller which first serves your form and then processes the submitted inputs.
You can take a look at the ckanext-pages extension, which does exactly that (for editing static pages instead of datasets, but your code would be similar).
the TYPO3 documentation here https://docs.typo3.org/typo3cms/ExtbaseFluidBook/6-Persistence/4-use-foreign-data-sources.html says, it is possible to use external data sources for extbase objects: "These foreign data sources could be tables from the same TYPO3 database or a web service."
The used data mapper allows at least to map objects to any table within the same MySQL database.
I am interested in this "or a web service" part. How to configure the data/property mapper to fetch and store an extbase model from an external web service (e.g. REST)?
Is it already possible with TYPO3 core? If not, does anyone know an extension which such capabillities?
You are looking at very old documentation there. Although this is still valid to learn Extbase concepts, I would not recommend the ExtbaseFluidBook for hardcore-details any more. I suppose the claim you quote reflects more of a wish or a slight possibility, not a reality. I am not aware of anybody having gone that route yet.
If I wanted to make an external source look "Extbasey", I would implement a repository and models but just use own logic to select and persist.
Side note: Typo3 v8 integrated doctrine, but only working with records, not objects (-dbal, not -orm): https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Database/Introduction/Index.html - this is used more and more in the core and in extensions. It might be feasible to include doctrine-orm and a doctrine-REST-backend like https://packagist.org/packages/circle/doctrine-rest-driver.
I'm developing a wiki engine. Since this application can be usefull (at least for my company's private use) in its own it should be able to run as a standalone pyramid application, with its own graphical theme.
However a wiki feature could also be useful as part of a bigger project, and I would like to be able to include it into other pyramid applications.
I already found some pyramid features that could help me to achieve this but first I'm not sure whether it's the best way to do it and second some problems remain open.
Here are the potential issues I currently see:
templates: how to switch between the standalone mode and the hosted mode
host variables: event if we can reuse the host template, some variables may be needed to correctly render the templates but are not set by the guest (the wiki engine) application.
authentication: the guest app defines its own login system (based on pyramid_persona). Can the guest application reuse the host authentication system?
My current idea is to use the config.include() system of pyramid. In the wiki engine, in __init__.py I then define an include(config) method in addition the the main() method used for the standalone mode.
In the host application I then define a variable in the .ini file which points to the template file that the guest should use (ie base_template = hostapp:templates/wikibase.mako)
Inside the guest application, the includeme() method reads the base_template variable and overrides some global config.
Then each guest view work like this:
from pyramid.renderers import render
#view_config(route_name="display_wiki_page", renderer=Globals.base_template)
def view_wiki(request):
"""returns a formatted page content"""
page = request.matchdict['page']
content = get_raw_page_content_from_database(page)
page_formatted = render("wikiengine:templates/page_formatting_template.mako",
{'request': request, 'content': content} )
return {'page_formatted': page_formatted}
So from this point the base template can either be the one from the guest or the host application. Both will contain something like (in mako): ${page_formatted | n }
But this does not solve the problem of necessary host variables for the template to be rendered by the guest code. For example the host may need to have a hot_news variable that need to be displayed on each of the host pages, even the pages that host the wiki.
For this I plan use the event system, and add a subscriber for NewRequest or BeforeRender and set the needed variables here inside the request object.
Is this a correct approach ? Are there examples of what I'm trying to do?
Pyramid's configuration mechanisms make it very easy for clients of a module to override configuration. This is one of the most powerful parts of Pyramid compared to other popular web frameworks.
config.include() is a good approach to solving the problem. It allows the caller to override anything defined within the include.
Assets can be overridden using config.override_assets().
Sharing user information requires your module to either provide the user information or define a contract to which someone can conform allowing them to override your model.
Anyway this is obviously a huge topic. Highly modular apps written on top of pyramid include substanced, kotti, ptah, bookie, etc.
I am trying to simulate an intranet CMS and installed the eu_ldap extension for typo3. Unfortunately the downloaded guide is out of date, and the current manual is of very little use to a typo 3 beginner.
Is it possible to create nodes from within the extension or it has to be defined in the ldap server? Or can users can be created within typo3 then be authenticated via ldap or whether it has to be done on the OS. I'd like to build an intranet system and create users who can create resources using other extensions but I would like to structure access control also. In short I don't understand which functionalities are delegated to the extension and which have to be structured on the server side.
At the moment my best guess as to how to create the domains is to create a domain object with each page that acts as a domain root which will correspond to a node within the ldap (e.g. ou=Members) then create an ldap server object in typo 3 on that page, assuming this works (if it is the way to go about it) how can users be created and given acls? then added to this domain for instance?
The extension just provides the authentication service. So can connect the TYPO3 to your ldap by providing the connection data in the extension and then every login attempt is not checked on the TYPO3 side, but redirected to the ldap system. This just sends back whether the user is allowed to login and may provide some more information about the user and the assigned groups.
The ldap system does not know anything about the structure inside your TYPO3, but you can use the groups for access restrictions.
Most of the ldap extensions work like that and depending on whether you want to provide login to frontend, backend or both, there may also be better extensions for your case. You have to be a little more specific on
I'd like to build an intranet system and create users who can create resources using other extensions but I would like to structure access control also.
What kind of resources do you want them to create? Does that mean frontend or backend? What exactly do you want to have an access control for? Pages or content or plugins/extensions or backend modules?
I am planning a Catalyst application, that will be deployed over a number of servers. It will be used internally by support staff to control aspects of an operational system that runs on those servers.
The application will run much in the same way on each server, save for a limited amount of site specific behaviours. Some actions will only apply to some servers, and some actions will behave differently on other servers.
Are there any recognized design patterns/practices that enable site-specific customization of a Catalyst application?
I am currently thinking of deploying a site configuration file alongside the application, that will be used to determine what actions to enable, and set parameters that control other action's behaviour. Ideally this customization would happen when the application is loaded by mod_perl (Apache2) - but I am not sure if that would even be possible.
Any suggestions welcome!
Catalyst::Plugin::ConfigLoader has code to help you with site-specific configuration in the form of the MYAPP_CONFIG_LOCAL_SUFFIX environment variable. Since Controllers are Components and config is available at setup_components time, you can do whatever foolery you want with action registration when your controller is compiled. There's not much pre-rolled for it, because everyone's requirements are so different, but it's not exceptionally hard, and there's advice to be found on the mailing list.
You can set templates, or have conditional behaviour in the controllers based on the value of $c->req->host.
I always use the unique combination of $HOSTNAME and $USER to define the specific configuration file to be loaded, e.g.
conf => "my_app_${hostname}_${user}.conf"