I'm creating a wiki where users edit content in one namespace, and the
"results" are displayed in the Main namespace.
I'd prefer to create no new namespaces.
Is it safe to use the "Barry Carter's Wiki" namespace (ie, the wiki's
name namespace) for my 'edit content' namespace?
There are a number of pages in the wikiname namespace (the canonic name for it is Project namespace, by the way) which will get linked from various places; e. g. Project:Copyright will be linked from the copyright notice on the bottom of the screen. If you are not bothered by that, I don't see any problems. (You should check out the FlaggedRevs extension, though.)
Related
So I'm currently working myself through the following introduction about extension developement for TYPO3:
https://docs.typo3.org/m/typo3/book-extbasefluid/9.5/en-us/4-FirstExtension/4-make-products-persistent.html
There it says
TYPO3 is able to group all records of an extension in the new record wizard. To define the name of this group, create a language file in the directory EXT:store_inventory/Resources/Private/Language/ and add the key extension.title.
What do I therefore have to name the language file (you might also want to check the link) for it to work and what exactly is meant by "add the key extension.title"?
Filenames of language files are created with several patterns
typo3conf/ext/extkey/Resources/Private/Language/locallang_db.xlf
Is used in Backend i.e. for displaying the name of the tables, names of fields in the backend edit form, plugins etc. Naming convention here is rather strict. i.e.:
<trans-unit id="tx_extkey_domain_model_yourmodel.name">
<source>Name</source>
</trans-unit>
can be used in the TCA of your model like:
'name' => [
'exclude' => true,
'label' => 'LLL:EXT:extkey/Resources/Private/Language/locallang_db.xlf:tx_extkey_domain_model_yourmodel.name',
'config' => [...],
],
typo3conf/ext/extkey/Resources/Private/Language/locallang.xlf
Is used in FrontEnd, so for an instance
<trans-unit id="my_list_header">
<source>This is list of my elephants</source>
</trans-unit>
can be accessed within your Fluid template like
<h1><f:translate key="my_list_header"/></h1>
Note: as you can see naming convention for id/key, in this case, is more flexible, then in case of *_db.xlf files.
typo3conf/ext/extkey/Resources/Private/Language/locallang_csh_tx_extkey_domain_model_yourmodel.xlf
Is for adding CSH - Content Sensitive Help
<trans-unit id="name.description">
<source>That's just the record's name Sherlock!</source>
</trans-unit>
In Backend looks like:
You can also add [fieldname].details node to XLIFF file and then it will allow displaying more detailed help for the field in the popup window.
<trans-unit id="name.details" xml:space="preserve">
<source>Sherlock Holmes (/ˈʃɜːrlɒk ˈhoʊmz/ or /-ˈhoʊlmz/) is a fictional private detective created by British author Sir Arthur Conan Doyle.</source>
</trans-unit>
TIP
Although learning of creating TYPO3 extensions from the scratch is quite romantic I'd suggest starting from installing extension_builder extension and creating own extension's skeleton within minutes or even seconds. It will create most of the required elements, like SQL insertion, language files, TCA and TypoScript configuration files and many more, so you can investigate it against tutorial easier.
About the key
I may be wrong, just don't remember now, probably extention.title was some approach in a pre-Extbase way, years ago. Nowadays I didn't meet it in any extension which works with ver 9.x or 10.x. It's obviously missing part in documentation you mentioned in yor question and it should be rather fixed there, to be more detailed.
I would have thought that your file should be extention.title
Choices:
create an asset bundle (nicely explained by Ivo Renkema at How do I manage assets in Yii2?). this is what I need if I want to package my code for other use. alas, should I also do this for my own php include library functions? Or should I still stick them into the same php location as my other php files? In any case, if I want to go this route, presumably I would then customize the AppAsset class, included in the template, as explained in http://www.yiiframework.com/doc-2.0/guide-structure-assets.html .
stick my files directly into $basePath/web, where $basePath is typically something like /var/www/myapp/ (i.e., as $basePath/html/mine.html [and refer to it simply as href='/html/mine.html'], $basePath/css/mine.css , $basePath/js/mine.js, and $basePath/php/mine.php [and refer to it as $basePath= \Yii::getAlias('#webroot'); require_once('$basepath/php/mine.php') ])?
stick my local files where my php view code sits. the advantage is that the files are close to where I will use them. the disadvantage is that I may litter the view directories not only with php files, but also with my non-asset assets, even though they will be used only by these (my) php files.
it's a beginner's question for the google cache reference. it's about best practice when getting started. I can guess the answer, but we wouldn't want a novice to disseminate bad info.
If you need your CSS and JS files only in one view or one Controller you have 2 choices:
1- Create a asset bundle Here other guide if you need it.
2- Use registerJsFile() from View Class
You can acces from controller using:
Yii::$app->view->registerJsFile('js.path');
(Same with CSS files but using registerCssFile())
With the PHPfiles I always try to convert the code to yii's MVC. If you have a entire library try to add it as a component. Here a usefull guide
In MediaWiki skin definitions, the BaseTemplate that gets extended has several attributes for creating links to other pages in the wiki, but I've got a situation where I need the path to the skin's directory, to pull some images used to create the UI. By default, that would just be /skins/mySkin/images/foo.png, by default but if someone changes the $wgStylePath variable, or renames the skin, that would be an issue. Is there an existing variable that has that URL build out, hidden somewhere in the BaseTemplate methods?
Yes, the SkinTemplate class, which contains the code to set up the template variables before executing the template, provides access to $wgStylePath via the 'stylepath' template variable.
When you subclass SkinTemplate to define your skin's main class, you are also expected to override the $stylename member variable, which specifies the subdirectory under which your skin's own stylesheets and images reside. (This would usually be the same as the name of your skin in lower case, but it doesn't have to be; it's perfectly fine to have, say, two related skins using images from the same directory.) This is also made available as a template variable, surprisingly named 'stylename'. So one way to specify an image path in your template would be something like:
<?php $this->text('stylepath') ?>/<?php $this->text('stylename') ?>/images/foo.png
Another way, (formerly) used e.g. by the Vector skin, is to use the getSkinStylePath() method from the Skin class (which is the superclass of SkinTemplate; it's kind of messy and tangled for historical reasons, but basically you can pretty much treat them as one class split into two files).
Update: As of MediaWiki 1.36, getSkinStylePath() has been deprecated. The recommended alternative, according to the release notes, is to "replace usages with the direct path to the resources."
To use it, you pass in the name of the file as a parameter, and the method automatically prepends $wgStylePath and $stylename to it (and appends $wgStyleVersion as a query string). Note that this is not a template method, so you have to escape and print the returned URL yourself:
<?php echo htmlspecialchars( $this->getSkin()->getSkinStylePath( 'images/foo.png' ) ) ?>
There's also a getCommonStylePath() method which does exactly the same thing, except that it uses the string "common" instead of $stylename.
Apparently this is the new way:
$this->getSkin()->getConfig()->get( 'StylePath' ) . '/SkinName/images/foo.png';
Source: https://phabricator.wikimedia.org/T270754
I have a project containing a big package "global" of classes which is designed for Web, I need to share these classes with a new mobile project, but when i add them with :
Properties -> Flex Build Path -> Source path -> Add Folder
they start appearing with index [source path] before the package name, and since them Flash Builder start trowing error messages :
"A file found in a source-path must have the same package structure '', as the definition's package, 'global'."
How can i fix this issue ?
As we've discussed in the comments, I think it would be a better approach to compile your "global" classes into a library (.swc).
You were concerned about loading unnecessary classes: when you link to a library as 'merged', only the classes you use are actually compiled into the main application (and any classes they depend on), so there's no need to worry about that.
As a last argument I also think this is a more flexible approach. A compiled library is easier to reuse and version, so the code can more easily be distributed to other developers on your team.
Rename one of the packages with right click->refactor. Than is should work.
If not you can also try to have your two codes available at the same project, and then you can select which to run in Flash Builder, by right-clicking to that .as or .mxml file, and selecting set as ... (or something like that)
I guess if you will include 'src' fonder instead of 'src/global' that problem will disappear.
I renamed a folder and updated my namespace declarations, but ReSharper 6 claims that the namespace should be a reflection of how it was before the rename. Where is it storing the file location data?
Check to make sure your assembly name matches your new namespace. If you've changed your folder structure to match your new namespace, you may still see the ReSharper alert until you update the project properties.
As delliottg's comment says, in Visual Studio, go to
Project > [project name] Properties > Application
and change "Assembly name" as well as "Default namespace".
I also had this problem with a folder/namespace and none of the above steps fixed it.
In my case I had to do this in Visual Studio:
Right-click the "problem" folder in the solution explorer to open the properties
Ensure the "Namespace Provider" is set to true
This fixed the ReSharper issue for me and I was able to adjust namespaces as normal.
Root namespace is needed to be changed as following.
I use Resharper 2019.3.2 in VS 2019 vs 16.5.2 and I had similar issues.
When developing, I first work out my namespace hierarchy in a single project, then split the project in seperate class libraries. In the first stage, it is convenient to always let the subdirectory correspond to the namespace.
For example, my prototype MeshTools.dll project currently contains:
Meshtools ........................ 3 cs-files in \MeshTools
MeshTools.HeightField .......... 2 cs-files in \MeshTools\HeightField
MeshTools.VectorTools .......... 3 cs-files in \MeshTools\VectorTools
The above answers all assume one single namespace per project. Renaming directories manually may confuse Resharper and that can be repaired by setting the default assembly in the .csproj file to the proper namespace. Thanks for the tip.
However in my case, I have several namespaces in a single project, with each namespace in a Solution directory corresponding to a real directory. Setting the default assembly "Meshtools" does not affect ReSharper behaviour for HeightField and VectorTools, when things have gone wrong with the renaming.
I googled this issue and came by https://www.jetbrains.com/help/resharper/Refactorings__Adjust_Namespaces.html#
It turns out there is a right-click option on a Solution Directory -> Properties. You will find an option to decide, if the Solution Directory is a NameSpace provider or not. When something has gone wrong, Visual studio will reset the field to False. Set it back to True and Resharper will correctly refactor namespace or file location when needed..
If you're using JetBrains Rider, go to the Solution Explorer and right click on the csproj file, then properties in the context menu. In my case the Assembly Name was already updated but "Root Namespace" wasn't, updating Root Namespace allowed JetBrains to automatically update all namespaces.