Closed lukasoppermann closed 2 years ago
Good idea ! Actually, the differents status are hard coded, maybe need a little refactoring.
Why not a markAs
method with a parameter ? Personally I prefer it, I don't like magic :wink:, and like idea completion.
Hi @lukasoppermann, this is a very good idea.
The quickest way I can think of, is to use the config file to define the available statuses instead of the Status
model.
What do you have in mind about magic methods?
@hootlex I think $post->markNotForChildren()
(status = not_for_children), like the markPending
method ( See call magic method ).
@stephane-monnot @hootlex exactly. But I would be fine with a markAs()
method. It was a suggestion in case you wanted those methods.
Changing the status to be defined in a config file would make sense to me. This would even open it up to be stored in a database, retrieved and set as config variables, so it would make it very flexible!
However it needs a little bit of though as you would need to let the user define if a status is by default retrieved or not. But it should be easy.
I am just thinking that sometimes you need to create a business flow, e.g.
"new Post() created", status: ->
draft ->
waiting for review ->
needs changes ->
waiting for review ->
ready for publication ->
published / queued
Just as an example.
You could change everything to just use more generic functions like setStatus()
and hasStatus
.
If you want to keep the old behaviour to not break bc you could just create them as "aliases" so markPending()
is an alias for setStatus('pending')
.
Maybe status are better in database (eloquent model), because:
What do you think ?
Hmm, maybe optionally? I am just thinking if you just have a published/unpublished case a database for just to status would be a bit of an overkill, would it not?
Yes, I agree, that's a bit overkill. As a first step, we should use config files.
Maybe we could require a "default" status or something so if the status that a model had is missing, it will be reset/interpreted as the default status? This could solve the problem you where describing correct?
Good idea !
@hootlex, what do you think ?
@lukasoppermann @stephane-monnot I prefer to use config file to define the statuses. They can be defined within an array, which will contain an 'ID' and a 'name'.
+1 for the default status fallback.
Hey, very nice package. However, if this flow does not work with your process, you need to hack it.
What do you think about adding a possibility to add a custom status?
E.g.
Maybe the user can set those status and decide if they should be queried in strict mode or not.
You could even use magic methods to build
markCustom
methods.What do you think?