Asked  2 Years ago    Answers:  5   Viewed   59 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?

 Answers

1

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, September 21, 2022
5

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.

[Edit]

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

Wednesday, October 26, 2022
 
4

Scott Meyers tackles this issue in Item 7 of his fantastic "Effective Modern C++". He runs through the differences, pros and cons of both syntaxes, and concludes

There’s no consensus that either approach is better than the other, so my advice is to pick one and apply it consistently.

On the other hand, the C++ Core Guidelines suggest that you prefer the initialiser syntax, so perhaps that's the better default to go for.

Friday, October 14, 2022
 
3

The compiler is making its decisions based on static code analysis, whereas if you profile as don says, you are carrying out a dynamic analysis that can be much farther reaching. The number of calls to a specific piece of code is often largely determined by the context in which it is used, e.g. the data. Profiling a typical set of use cases will do this. Personally, I gather this information by enabling profiling on my automated regression tests. In addition to forcing inlines, I have unrolled loops and carried out other manual optimizations on the basis of such data, to good effect. It is also imperative to profile again afterwards, as sometimes your best efforts can actually lead to decreased performance. Again, automation makes this a lot less painful.

More often than not though, in my experience, tweaking alogorithms gives much better results than straight code optimization.

Tuesday, August 16, 2022
1

Your code is correct absolutely there is no error in it but its other things failing encoding. As I need message source headers and message to tell you exactly what is happening? I have further no information about are you sending the email as plain text or HTML. But there are generally two issue which are:

Missing Mime-Version

Reason for showing the character wrongly is developers forget to describe the message as MIME Version. if the message is missing the "Mime-Version" header that Internet mail standards require, Webmail will ignore the "charset" header completely, garbling the message unless it's already in the UTF-8 character set.

Showing Subject with Special Characters

As you want to show the subject with utf-8 encoding then you must encode the subject as:

//Setting the Language as Japan
mb_language("ja");

//Converting the string into Japan Encoding
$subject = mb_convert_encoding($subject, "ISO-2022-JP","AUTO");

//Now convert the string to MIME Header type
$subject = mb_encode_mimeheader($subject);

If the above mentioned things doesn't resolve the problem then request you post the RAW Headers of the Email as it will help in better way to resolve issue.

Friday, November 4, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 

Browse Other Code Languages