Tom tom--

I've had it up to here with the phony neo-romanticism of "epic" bike rides.

It started, as I recall it, with Rapha's monochrome marketing images of beautiful young men riding bikes and drinking black coffee in over-understated euro-chic clothing and without helmets, which spoil the look. The presentation always came with some implied or overt association with the history of pro bike racing and the heroism and torment of long hard bike rides.

The monochrome photography has become a mark of the genre. Its canonical form is film of Paris-Roubaix with soundtrack replaced by plaintive, soulful music to express the, passion and suffering, plenty of slow motion, maybe some amped-up contrast, images of muddy-faced cyclists, many of them disconsolate at the side of the road, out of the race due to a crash or equipment failure. The correspondence with Wagner or ETA Hoffmann disturbing: bombast, bogus mythology, Ach Weh, escapism and all that incoherent rot.

It quickly became—to what extent by clever engineering, I

Question: "I would like to know if it good idea to use Yii for developing..."

First, are you sure that:

A server-side webapp is what's needed?
MVC is the right architecture for the requirements and not, say, CMS?
PHP is suitable for your situation?

If yes to all then Yii might work well for you and is worth considering. Start reading the user guide and take the demo app for a test drive. If you like it then you may be getting closer to an answer to the original question. If not then there are alternatives for you to try.

Yii 2 basic vs. advanced apps

The names of the two demo apps, Basic and Advanced, can be unhelpful. Many people end up choosing advanced just because of the name even though basic would suit them better.

The key differences are:

Advanced has a complex system of configuration. It is designed so that a team of developers can work together on a project keeping everything, including app config, in VCS but each developer can customize their own config for development, testing and other environments.

This configuration arrangement can be confusing and is often unnecessary. If you are working alone, you'd probably want to avoid it.

I have an interesting Yii 2 AR design problem.

The DB has 12 primary entity tables related via a full mesh of 72 join tables. Each relation also has a type (and attributes) but those aren't stored in the join tables – they are in additional tables that the 72 join tables reference. So each of the 72 join tables provides a 3-way join between one entity, another entity and another table called link that points to the link_type.

My problem is to write the AR models and relation methods.

Let's make this more concrete with two of the primary entities: artist and recording, related through l_artist_recording. Each record of l_artist_recording has an FK to the link table, through which I can load the link_type name. For example, an artist-recording relation might have link_type "performer", "conductor", or "producer" etc.

This is a simplified schma good enough for thinking about the AR p

I'm trying to decide how to model relations where one type of entity is owned by one of several other types of entity. For example, my app involves scheduling. A schedule entry (which corresponds to one record in a schedule table) looks pretty much the same regardless what it belongs to: a meeting, a publication, a broadcast.

Options I considered:

One schedule table with three nullable FKs to the meetings, publications, and broadcasts tables. It doesn't enforce the constraint that for each row, one and only one of the three FKs must point to an existing PK in its corresponding foreign table.
One schedule table with a "polymorphic FK" column and an FK type column indicating to which of the foreign tables the "polymorhpic FK" points. This admits no DB constrains and is just horrible.
Three schedule tables meeting_schedule, publication_schedule and broadcast_schedule each with one proper FK to its owner table. Solves the constraints problem but I need to run queries over all schedule

PHP RFC: Nullable Return Type Declaration

  * Version: 0.1
  * Date: Apr 14 2016
  * Author: Tom Worster, fsb@thefsb.org
  * Status: Under Discussion
  * First Published at: https://wiki.php.net/rfc/nullable_return

	<?php

	function constructTotalizer() {
	$privateTotal = 0;

	$privateAddTotal = function ($n) use (&$privateTotal) {
	$privateTotal += $n;
	};

	$publicAddTotal = function ($n) use ($privateAddTotal) {

	<?php

	namespace spinitron\controllers;

	use Yii;
	use yii\web\Controller;
	use yii\web\Session;

	class WizardController extends Controller
	{

	<?php

	namespace yourapp;

	use yii\helpers\StringHelper;

	class Security extends \yii\base\Security
	{
	/**
	* Extends yii\base\Security::generateRandomKey() to use suspicious OpenSSL setups if

	<?php

	$tests = [
	"function_exists('random_bytes')",
	"defined('OPENSSL_VERSION_TEXT') ? OPENSSL_VERSION_TEXT : null",
	"PHP_VERSION_ID",
	"function_exists('mcrypt_create_iv') ? bin2hex(mcrypt_create_iv(8, MCRYPT_DEV_URANDOM)) : null",
	"DIRECTORY_SEPARATOR",
	"sprintf('%o', lstat('/dev/urandom')['mode'])",
	"sprintf('%o', lstat('/dev/urandom')['mode'] & 0170000)",

Tom tom--

Yii 2 basic vs. advanced apps

PHP RFC: Nullable Return Type Declaration

Introduction