renaming custom operation in api-platform - api-platform.com

I'm modeling one entity that has a prepare-release workflow. So in addition to the ordinary POST action to create the entity, I also have a second POST custom operation to set it active. This triggers considerable backend activity which is why I implement it as a custom operation and not as a simple update on a property (PUT).
So far so good, however in the API interface documentation, it still describes the operation as "create a xxx resource", which is false. I found no way to change this description. How can I put a different text there?

actually figured out from a totally unrelated post (https://stackoverflow.com/a/49534635/982364) that this works:
* collectionOperations={"post", "special"={
* "method"="PUT",
* "path"="/myentity/{id}/commit",
* "controller"=EntitySpecial::class,
* "denormalization_context"={"groups"={"myentity_commit"}},
* "swagger_context" = {
* "summary" = "commit to this action"
* },
* "defaults"={"_api_receive"=false}
* }},

Related

How do I format OpenApi in swagger-php so that the swagger-ui shows a form instead of an array?

I'm on a Laravel build, and updating notations for all my API controller methods from #SWG to #OA. When I hit 'try it out' in the swagger-ui on a create method, I'm able to get it to show (and accept) an editable array of parameters and values (the latter being the examples I coded in), but I'd much rather get a form of the given parameters instead, to be sent in the body, not the query. I was able to do it in the older version by adding parameters and setting the 'in' parameter to 'body', but the documentation says I have to use requestBody now. Not terribly pleased with the results...functional, but not optimal.
Here's an example of a requestBody I'm using currently:
/**
*
* #OA\RequestBody(
* request="Answer",
* description="Answer object that needs to be added.",
* required=true,
* #OA\JsonContent(ref="#/components/schemas/Answer")
* )
*/
I suspect I need to do something with #mediaType, but when I try it, with a list of parameters, it doesn't give me anything 8(
What am I missing?
I was conflating the requestBody with the response...thought I'd need to send in json to get back json. Nope lol Just needed to send it with a form-data mediaType.
Here's what I ended up with, in case it helps someone:
/**
*
* #OA\RequestBody(
* request="Answer",
* description="Answer object that needs to be added.",
* required=true,
* #OA\MediaType(
* mediaType="multipart/form-data",
* #OA\Schema(ref="#/components/schemas/Answer")
* )
* )
*/

efficient way to display subset of Doctrine collection in twig

I've got a Symfony entity, which has a OneToMany mapping with an OrderBy clause like this:
/**
* #ORM\OneToMany(targetEntity="App\Entity\News", mappedBy="category", orphanRemoval=true)
* #ORM\OrderBy({"id" = "DESC"})
*/
private $news;
Assuming I would like to only display n entries in Twig, I would have the options to either loop over it and ignoring every thing after loop.index n or rather use slice. However these options do have the downside, that if there are a lot of news entries, all of them will be loaded, which isn't very efficient.
Another option would be to use a Criteria in the controller or the entity to limit the amount of loaded entities. If I understood it here correctly, it should modify the doctrine query directly and thus not have any performance impact. Is this the best practice, or would it be better to have a custom query builder in the controller or a function in the repository?
Actually you can set $news relationship as EXTRA_LAZY and use $news->slice() function without triggering a full load as stated in official documentation:
If you mark an association as extra lazy the following methods on
collections can be called without triggering a full load of the
collection:
Collection#contains($entity)
Collection#containsKey($key) (available with Doctrine 2.5)
Collection#count()
Collection#get($key) (available with Doctrine 2.4)
Collection#slice($offset, $length = null)
Therefore your declaration should look like the following:
/**
* #ORM\OneToMany(targetEntity="App\Entity\News", mappedBy="category", orphanRemoval=true, fetch="EXTRA_LAZY")
* #ORM\OrderBy({"id" = "DESC"})
*/
private $news;

Programmatically adding default image to content type

Is there a way to add a "default image" file to a content type field, using features, a module or anything. The only way I have found so far is adding the image link to each node created without an image, but I was wondering if I could use something better and recommended
I found some related info here question.
-- EDIT --
To clarify, I do mean "a default image for a image field in a content type"
BUT, I am creating the content type using features and a the site using a script. I cannot use the form or anything related as I will potentially NEVER touch the site myself. I want to automate it all (:
Thanks!
Default images won't come across in features, but you can use hook_field_default_fields_alter in a module to set the default image for that field.
Here's a discussion on it on the Drupal site:
https://drupal.org/node/1439136
comment 6 is a single use case which you could adapt for your field, while comment 7 is a more general solution which you can use for several fields.
I have been meaning to try something similar. Not sure exactly how it will work but the genral idea is as follows:
Create a rule - on insert of the content Type.
Have the rule set a data value which will be the image.
In my case I intend creating a new content type (ImageNodes) that will simply be a small, static set of nodes. Each ImageNodes node will consist of a key and an image. When setting the data value in my rule I will inspect another field in the content being inserted and use that as a reference to the correct ImageNodes node.
This approach will allow me to attach default images to my content nodes on insert, to allow it to attach alternate images based on the contents of the inserted node.
Note, this approach can be implemented with the image being created as an entity reference (or similar), or alternatively the rules module is smart enough that I can copy the image field in the ImageNodes node to an image field in the content node being inserted. Adding a condition to the rule will give you the ability to only inject the default image if none has been selected.
The following code I adapted from Features issue #1439136: Support imagefield default images on drupal.org to work with Features API version 1.
It can easily be adapted though to work with Features API version 2 by changing the hook name as described in the notes and comments below.
This code sample should be added to your main module file modulename.module. I would suggest it is best to add to the features module where the entity and fields are defined. It should work with any Drupal fieldable entities. I've used it with users, nodes, taxonomy vocabularies, and field collection items.
To implement this in your own module, copy the code below and then:
Replace all occurrences of modulename with your module machine name.
Define all your field image defaults in the array returned by modulename_images_fields_defaults().
Place your default images into your module path using a folder named images.
Notes:
Field machine names can easily be located and copied from the Features API 1 file named modulename.features.field.inc.
In Features API 2 the fields definition is split into modulename.features.field_bases.inc and modulename.features.field_instances.inc, so the hook also is renamed and can be used for either the field base or field instance:
hook_field_default_field_bases_alter()
hook_field_default_field_instances_alter()
Code:
<?php
/**
* Define images for use as defaults in fields info.
*
* #return array
*/
function modulename_images_fields_defaults() {
return array(
'node-content_type_name-field_image' => 'default-image.png',
'field_collection_item-field_collection_item_field_name-field_image' => 'default-image.png',
'taxonomy_term-vocabulary_name-field_image' => 'default-image.png',
);
}
/**
* Implements hook_field_default_fields_alter().
*
* Alter field default values right before fields info is cached by features.
*
* #todo: Update to hook_field_default_field_bases_alter if Features upgraded.
*
* #param &$fields
* By reference. The fields that have been declared by another feature.
*/
function modulename_field_default_fields_alter(&$fields) {
$source = drupal_get_path('module', 'modulename') . '/images';
$destination = file_default_scheme() . '://default_images';
$field_default_images = modulename_images_fields_defaults();
foreach ($field_default_images as $field_name => $filename) {
if (isset($fields[$field_name])) {
_modulename_field_default_fields_alter_image(
$fields[$field_name], $filename, $source, $destination
);
}
}
}
/**
* Alter image field default using managed source file.
*
* #param $field
* #param $filename
* #param $source_path
* The source folder path relative to the Drupal root where the image
* filename can be found.
* #param $destination_uri
* The destination folder path as a stream wrapper uri ie. "scheme://target".
*/
function _modulename_field_default_fields_alter_image(&$field, $filename, $source_path, $destination_uri) {
// See if a default image hasn't been set for this field yet
if (!isset($field['field_config']['settings']['default_image'])
|| empty($field['field_config']['settings']['default_image'])
) {
// Dynamically set the default image on the field
$source_file_uri = "$source_path/$filename";
// Check to see if managed file exists.
$result = db_select('file_managed', 'f')
->fields('f', array('fid'))
->condition('f.uri', "$destination_uri/$filename")
->execute();
$fid = $result->fetchField();
// Simulate an upload of the default image.
if (!$fid && file_exists($source_file_uri)) {
$file = new stdClass;
$file->filename = $filename;
$file->timestamp = REQUEST_TIME;
$file->uri = $source_file_uri;
$file->filemime = file_get_mimetype($source_file_uri);
$file->uid = 1;
$file->status = 1;
$file = file_copy($file, $destination_uri, FILE_EXISTS_REPLACE);
$fid = isset($file->fid) ? $file->fid : '';
}
$scheme = file_uri_scheme($destination_uri) ?: file_default_scheme();
$field['field_config']['settings']['default_image'] = intval($fid);
$field['field_config']['settings']['uri_scheme'] = $scheme;
}
}

$input->getCmd('task') what is 'task' in JOOMLA

i was digging this piece of code in JOOMLA
$input = JFactory::getApplication()->input;
$controller->execute($input->getCmd('task'));
80% i understood but stuck at 'task' thing.
Documentation says that getCMD
* The default behaviour is fetching variables depending on the
* current request method: GET and HEAD will result in returning
* an entry from $_GET, POST and PUT will result in returning an
* entry from $_POST.
*
* You can force the source by setting the $hash parameter:
*
* post $_POST
* get $_GET
* files $_FILES
* cookie $_COOKIE
* env $_ENV
* server $_SERVER
* method via current $_SERVER['REQUEST_METHOD']
* default $_REQUEST
i just search almost all variable in netbeans debug session but unable to find task variable.
Now my question is what this 'task' thing points to ? what it represents?
Basically a task in joomla 2.5 represents a function in a controller of your component. When you have an url like index.php?option=com_foo&task=comment.edit the function "Edit" in the controller Comment of the component com_foo is called.
For example here is a controller DPAttachmentsControllerAttachment with a download function
The url looks like index.php?option=com_dpattachments&task=attachment.download.
Hope this is what you are looking for.

Laravel 4: how can I understand how it all works?

I am using Laravel 3 in one project and it's been a joy. I have also looked at the source code several times to see how some things work behind the scenes.
But now in Laravel 4, I don't know where to begin or how to understand it all. Where can I learn all the behind the scenes of Laravel 4?
Case in point: I wanted to find out if the DB::insert() returns the id of inserted row. So I started searching.
1. I found the Illuminate\Support\Facades\Facade class that "encapsulates" DB.
2. The resolveFacadeInstance function is called and then I tried to print these arrays, but my computer hangs :-/. And I'm sure this would lead to many more classes that I wouldn't understand.
Is there a way I could try to learn the inner workings of Laravel 4? Maybe stack traces?
The facade class is just a filter class to allow you to call methods as if they were static.
For the facade mappings go here: http://laravel.com/docs/facades#facade-class-reference
The starting point to fully understand laravel's inner-workings should begin at:
/public/index.php
You can follow the logic of the program, noticing that requires start.php, which loads an instance of the "Application" which is found here:
/vendor/laravel/framework/src/Illuminate/Foundation/Application.php
This Tuts+ video shows a couple of ways of finding out what class is actually doing the work.
E.g.:
$root = get_class(DB::getFacadeRoot());
var_dump($root);
You can check out the early docs for Laravel 4 here : http://four.laravel.com/ – that should give you a good starting point
The actual Laravel 4 code is well documented in the files. If you want to understand the inner workings then open up the source code files and read the notes. For example I looked up the DB::insert() code in /vendor/laravel/framework/src/Illuminate/Foundation/Application.php.
/**
* Run an insert statement against the database.
*
* #param string $query
* #param array $bindings
* #return bool
*/
public function insert($query, $bindings = array())
{
return $this->statement($query, $bindings);
}
Ok, so this is calling the statement function so I search for function statement in the same code / class:
/**
* Execute an SQL statement and return the boolean result.
*
* #param string $query
* #param array $bindings
* #return bool
*/
public function statement($query, $bindings = array())
{
return $this->run($query, $bindings, function($me, $query, $bindings)
{
if ($me->pretending()) return true;
$bindings = $me->prepareBindings($bindings);
return $me->getPdo()->prepare($query)->execute($bindings);
});
}
We can now see that this returns the boolean result based on the comments above the code.
If you come from Laravel 3 this article is for you. After that you should read the other tutorials of that series.
Author's note:
This article should outline some of the more important changes to Laravel between versions 3 and the upcoming version 4. Bear in mind
this isn’t all of the changes. As the release of Laravel 4 gets closer
I’ll keep this article up to date. If you’re having any problems with
Laravel 4 please jump on to #laravel on Freenode. At this time we’d
like to ask people not to post help topics on the forums.

Resources