In a Server Action how does one edit an object? (e.g. coming from a database single query)
If it were an array of objects I'd use the Repeat step with Set Values inside to define or redefine properties
In a Server Action how does one edit an object? (e.g. coming from a database single query)
If it were an array of objects I'd use the Repeat step with Set Values inside to define or redefine properties
Hi.
Assuming below structure as an example:
Single query step named query1 return some data.. which looks like:
"query1":{ "col1":"data1", "col2":"data2" }
To use it in a repeat, you can just add square brackets in the expression, to treat it like an array.
{{[query1]}}
This will not allow you to select the fields in the repeat step, so that part you will most likely have to handle manually.
Bummer, let's see if someone has another idea Thanks
Can you elaborate on what you mean, obviously a repeat is meaningless on a single record array.
What are you trying to achieve?
Extract and manipulate the contents or try to manipulate them directly?
Example I have a user object:
{
"id": 1,
"first_name": "John",
"last_name": "Smith",
"email": "example@example.com"
}
I want to mutate that object to have a column "full_name", so I can access {{user.full_name}}
. I don't want to write back to the database (but perhaps I could if the column full_name existed in the DB).
Making something similar to an Accessor:
In Laravel's Eloquent models, accessors are used to modify attributes when retrieving them from the database. Accessors are defined using the
getAttributeNameAttribute
method naming convention.Example 1: Formatting a Full Name
class User extends Model { public function getFullNameAttribute() { return "{$this->first_name} {$this->last_name}"; } }
Usage:
$user = User::find(1); echo $user->full_name; // Outputs: "John Doe"
Example 2: Formatting a Price with Currency
class Product extends Model { public function getFormattedPriceAttribute() { return '€' . number_format($this->price, 2); } }
Usage:
$product = Product::find(1); echo $product->formatted_price; // Outputs: "€100.00"
Example 3: Converting a Date to a Readable Format
class Post extends Model { public function getFormattedDateAttribute() { return $this->created_at->format('d M Y'); } }
Usage:
$post = Post::find(1); echo $post->formatted_date; // Outputs: "19 Mar 2025"
Example 4: Checking if a User is an Admin
class User extends Model { public function getIsAdminAttribute() { return $this->role === 'admin'; } }
Usage:
$user = User::find(1); if ($user->is_admin) { echo "User is an admin"; }
Example 5: Getting an Uppercased Version of an Attribute
class Article extends Model { public function getTitleUpperCaseAttribute() { return strtoupper($this->title); } }
Usage:
$article = Article::find(1); echo $article->title_upper_case; // Outputs: "LARAVEL ACCESSORS EXAMPLE"
Best Practices
- Always return a value in an accessor.
- Keep them lightweight (avoid heavy computations).
- Use them to format or enhance data for presentation.
Would you like more advanced examples, such as mutators or computed properties?
I just do this with views in the database, and then query the view rather than the table.
I actually have a table called contacts, and a view called contacts_full_name, exactly for the reason in your last example.
I’ve now got as many views in my database as tables, to do this for a ton of situations.
It means I can query from the database exact text strings that I need to display on the front end, without repeating manipulations in a server action or slowing down the front end by doing them there.
Changed my life!
I hope that helps @Apple …
(Also just to note, some folks have been saying that views slow down your database searches which has absolutely not been the case at all for me)
Wouldn't a set value step do the job for you?
Where the value of the set value step is:
{
"id": "{{query1.id}}",
"first_name": "{{query1.first_name}}",
"last_name": "{{query1.last_name}}",
"email": "{{query1.email}}",
"full_name" : "{{query1.first_name +' '+ query1.last_name}}"
}
There's a lot of redefinition there, you're essentially rebuilding an object. If it were an array, using a Repeat with a Set Value inside to add or override a property would be more professional, less error-prone
That is what i understand you wanted to do from the explanation above
Yes, the end-result is right, but the development process is not
Pseudo-code:
$user = DB::find(1);
$user->full_name = $user->first_name + " " + $user->last_name;
As you can see, I didn't have to rebuild the entire object, I only added the property I wanted on top of what existed
I was going to suggest RunJS at first, but then I saw that repeat can be configured.
RunJS is the best alternative to your pseudo-code.
Perform a Database Query even though only one record will be returned. Then use the Repeat step as usual to define/redefine properties.
Pushing the solution to the top of the hierarchy seems the most sensible to me…
Do it as a database view and it’s accessible from anywhere in your design as though the full_name field were actually a field in the database…
Of course that does involve working outside of the Wappler Database Manager which may not be everyone’s cup of tea.
It would be amazing if the database manager had a view builder…
I concur with Antony. Database views are extremely effective when extracting and combining data from multiple tables, especially when complex data manipulations or joins are involved. They can significantly simplify query logic and boost productivity due to the availability of data in required formats.
It's worth noting that the database isn't the only data source someone might be using. We'll look into creating an object manipulation component, similar to what we have for arrays - with actions like adding extra properties with values (same as the add columns in collections) and deleting properties of an object.
For something as simple as combining two fields, I would have thought it might be simpler to add an extra column in the table - a generated/virtual column, calculating first_name + ' ' + last_name. This is not supported by Wappler's DM manager (at least, when I last tried) but is a useful feature of most database systems (incl. MySQL, PostreSQL etc.).
But for many apps, this example is one of a gazillion situations where you need to combine strings, often from a range of tables…
The Wappler Database Manager needs support from other SQL tools where you write SQL for many large scale real world applications…
Certainly. But as a solution to the current issue, I think a generated column is a good option. (Also, I think this approach is probably not often considered by Wappler users, so I thought it might be useful to mention it.)
I think the opposite. I was not keen on the idea of the Database Manager in the first place, because there are so many existing tools which I can't think Wappler will ever match; the companies developing these tools essentially focus on one thing and probably have many times more developers than Wappler. Obviously, Database Manager is here to stay, but I think it should be limited in its scope, beyond which users can switch to dedicated software. Think of all the feature requests which could have been fulfilled and extra time devoted to greater stability in each release, etc... (IMHO)
Convert to custom query and then add somehing like "forname+' '+surname as fullname" to the field list?
Quick,simple and effective
Yes, I’m certainly fine going outside of DM for what I need…