Asked  8 Months ago    Answers:  5   Viewed   43 times

I've been handed a pile of code that includes a lot of require/include statments (mixed between require and require_once). Sometimes, the path has parenthesis around it, i.e. require_once (JPATH_COMPONENT.DS.'controller.php');, and other times there isn't: require_once $path;.

The php docs for include mention this, but aren't specific. Should I remove the parenthesis when I find them, or is it ok to leave them alone? When writing further require/include statements, are there specific cases where I should use them?



You are allowed to use parentheses in 'include/require' not because include allows it itself but because you can use parentheses around any string or number in PHP for grouping.

So for example, "dog" is equivalent to ("dog"), ("dog")."dog" is equivalent to "dog"."dog", etc.

Parentheses become useful when you use complex expressions involving calculations and string concatenations but in such a simple case, they are simply allowed and perform an unnecessary and harmless "grouping" of a single string value.

Wednesday, March 31, 2021
answered 8 Months ago

For Joomla! specific information use the Joomla Docs website at, it has a Developers page. While most documents have been updated for the 3.x series it's worth knowing that a lot of the 2.5.x articles are still relevant.

Joomla supports three main extension types — modules, plug-ins and components.

Joomla! Magazine had a series starting back in Feb 2013 on Extension Development as well.

Finally there are also a range of good books/eBooks, including official Joomla! Press titles, and 3rd Party books, the most recent I'm aware of is "Learning Joomla! 3 — Extension Development" from PackTPub. [Disclaimer: I own a copy of this book and know the author from the Sydney Joomla User Group that he co-ordinates & hosts each month.]

For K2, I would suggest the community forums and Google (as their developer focused documentation is, shall we say, very scarce).

The other good way is to look at how existing K2 extensions are written.

Friday, May 28, 2021
answered 5 Months ago

So I had a lot of fields and wanted to simply loop through them in my edit.php field to keep it clean. While all the answers offered were right they weren't easy to implement - got really messy really quickly, had trouble getting it to work, or couldn't figure out a cleaner way around it. I chewed on this for awhile and then today came across what is basically a field override.

The key:

The standard form field types are located in joomla/libraries/joomla/form/fields/. You should not store custom fields there, nor should you have to use this path in your own code, but the standard types are usually good examples.

The custom field types that belong to your component are usually located in administrator/components//models/fields. You can specify this or another path in your code

So, I copied checkbox.php to models/fields. Then, towards the end of the file I added the empty field before the checkbox tag:

<input type="hidden" name="'.$this->name.'" id="'.$this->id.'" value="0" /><input type="checkbox" .....

Now, whenever I need a checkbox the empty field is also written. May not be the most efficient solution but simple to implement and can hopefully help someone else.


As a note, with every Joomla update you would probably need to compare the versions in the core in case there was a change.

Saturday, May 29, 2021
answered 5 Months ago

From what I understand from Javadocs, JFrame.add calls the latter. It is a convenience method to get around the incompatibility between AWT's frame and Swings JFrame.

From javadocs for JFrame:

The JFrame class is slightly incompatible with Frame. Like all other JFC/Swing top-level containers, a JFrame contains a JRootPane as its only child. The content pane provided by the root pane should, as a rule, contain all the non-menu components displayed by the JFrame. This is different from the AWT Frame case. As a conveniance add and its variants, remove and setLayout have been overridden to forward to the contentPane as necessary. This means you can write:


And the child will be added to the contentPane. The content pane will always be non-null. Attempting to set it to null will cause the JFrame to throw an exception. The default content pane will have a BorderLayout manager set on it. Refer to RootPaneContainer for details on adding, removing and setting the LayoutManager of a JFrame.

Thursday, July 29, 2021
answered 3 Months ago

"NavigationWindow does not store an instance of a content object in navigation history. Instead, NavigationWindow creates a new instance of the content object each time it is navigated to by using navigation history. This behavior is designed to avoid excessive memory consumption when large numbers and large pieces of content are being navigated to. Consequently, the state of the content is not remembered from one navigation to the next. However, WPF provides several techniques by which you can store a piece of state for a piece of content in navigation history...."

Monday, August 16, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :