| # |
Apr 19th 2017, 13:48 |
crazycoder |
hmic, nono for json responses i do not want it |
| # |
Apr 19th 2017, 13:47 |
hmic |
if you want it serialized by condition, you can overwrite the corresponding toArray() and jsonSerialize() functions in the entity to respect some custom information to decide to include the _joinData in the serialized data |
| # |
Apr 19th 2017, 13:47 |
hmic |
as long as you are working with the entity, the hidden properties has no effect at all |
| # |
Apr 19th 2017, 13:47 |
hmic |
it does only affect the serialized data! |
| # |
Apr 19th 2017, 13:46 |
crazycoder |
i mean...if i not use $this->loadComponent('RequestHandler'); <-- does it affect other code? |
| # |
Apr 19th 2017, 13:46 |
crazycoder |
does it not affect the other code? |
| # |
Apr 19th 2017, 13:46 |
hmic |
as long as you do not use the serialized data, you will be fine |
| # |
Apr 19th 2017, 13:46 |
crazycoder |
yes right now i am building an API so the response is in json |
| # |
Apr 19th 2017, 13:45 |
crazycoder |
another component |
| # |
Apr 19th 2017, 13:45 |
crazycoder |
hmic, i use it from a component |
| # |
Apr 19th 2017, 13:43 |
hmic |
so your application code can use the data still. thats the whole idea |
| # |
Apr 19th 2017, 13:43 |
hmic |
the hidden property is only used when serializing it |
| # |
Apr 19th 2017, 13:43 |
hmic |
where do you use it? |
| # |
Apr 19th 2017, 13:43 |
crazycoder |
so i cannot change it "globally" |
| # |
Apr 19th 2017, 13:43 |
crazycoder |
hmic, yes i did it but sometimes i used it |
| # |
Apr 19th 2017, 13:41 |
hmic |
crazycoder, why not just add _joinData to the _hidden property of the respective entity? |
| # |
Apr 19th 2017, 13:41 |
inoas |
right? |
| # |
Apr 19th 2017, 13:41 |
inoas |
writing a path as a key should be okay |
| # |
Apr 19th 2017, 13:38 |
inoas |
not links ... humpf |
| # |
Apr 19th 2017, 13:38 |
inoas |
but that's for redirects only anyway... |
| # |
Apr 19th 2017, 13:38 |
inoas |
but as far as I know there is not |
| # |
Apr 19th 2017, 13:38 |
inoas |
hmic I would have prefered if there was a way to use <include> in .htaccess ;p |
| # |
Apr 19th 2017, 13:37 |
crazycoder |
https://gist.github.com/anonymous/3f55105fe22a4db8dd017285d140f383 <--- for this |
| # |
Apr 19th 2017, 13:37 |
crazycoder |
hmic, do you know if there is an alternative? |
| # |
Apr 19th 2017, 13:37 |
 dereuromark |
and then you have time to figure out how to warm up specific updated users and you got the perfect world :slightly_smiling_face: |
| # |
Apr 19th 2017, 13:37 |
hmic |
if thats what your routes work like... but no, they dont (hopefully) |
| # |
Apr 19th 2017, 13:37 |
dereuromark |
prefix the cache with sth that identifies him, this way you can invalidate only a part of the cache that needs updating |
| # |
Apr 19th 2017, 13:37 |
inoas |
"sounds reasonable" ;-) |
| # |
Apr 19th 2017, 13:36 |
inoas |
all caching breaks down ;p |
| # |
Apr 19th 2017, 13:36 |
inoas |
so every time some dude saves a document revision |
| # |
Apr 19th 2017, 13:36 |
inoas |
haha |
| # |
Apr 19th 2017, 13:36 |
hmic |
i'd just purge it for now :p |
| # |
Apr 19th 2017, 13:36 |
hmic |
you could do that, sure |
| # |
Apr 19th 2017, 13:36 |
hmic |
cahing is easy, invalidating a cache is hard |
| # |
Apr 19th 2017, 13:36 |
inoas |
so on write you would lookup the cache and remove the keys that are wrong |
| # |
Apr 19th 2017, 13:35 |
hmic |
you need something to invalidate the cache, whenever you use one |
| # |
Apr 19th 2017, 13:35 |
inoas |
I don't like "admin panel clear cache" buttons |
| # |
Apr 19th 2017, 13:35 |
hmic |
like i said in the beginning: yes! absolutely! |
| # |
Apr 19th 2017, 13:35 |
inoas |
however I am concerned about timeouts |
| # |
Apr 19th 2017, 13:35 |
hmic |
yes, if the cache is not warmed up, first access will be slow. who cares? |
| # |
Apr 19th 2017, 13:35 |
inoas |
and then simply write the cache |