So that we remember (or at least I don't forget :P)

Topic: So that we remember (or at least I don't forget :P) (Read 11042 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Re: So that we remember (or at least I don't forget :P)

Reply #15 – January 05, 2013, 01:07:17 pm

QuoteI split the template/theme crap because I know nothing about them and I like to keep my topics clean.

Your new years resolution is to be mean

QuoteBut the general question is: does it make sense?

I think it makes sense yes ... but we need the test monkey to chime in since I'm not sure what is currently being done with the attachments function in terms of additional refactoring. Makes no sense putting time in to code that may not be used or can't be merged in or just has to be rewritten to fit the new paradigm ... well other than for your own enjoyment

Follow-ups
- Re: So that we remember (or at least I don't forget :P)

Re: So that we remember (or at least I don't forget :P)

Reply #16 – January 05, 2013, 02:20:14 pm

Quote from: Spuds – January 05, 2013, 01:07:17 pm
QuoteI split the template/theme crap because I know nothing about them and I like to keep my topics clean.
Your new years resolution is to be mean

emanuele is innocent

Quote from: Spuds – January 05, 2013, 01:07:17 pm
QuoteBut the general question is: does it make sense?
I think it makes sense yes ... but we need the test monkey to chime in since I'm not sure what is currently being done with the attachments function in terms of additional refactoring. Makes no sense putting time in to code that may not be used or can't be merged in or just has to be rewritten to fit the new paradigm ... well other than for you own enjoyment

emanuele reminds Spuds of what he can do just for fun.

BTW, yes I'm not sure about anything so better ask!

Re: So that we remember (or at least I don't forget :P)

Reply #17 – January 23, 2013, 01:40:52 pm

I've missed this discussion, sorry. Or rather, I missed the occurence here, but we had it already on github in fact.

Thanks for playing around with them. It makes sense, as far as I can see, to handle attachments errors in a separate class. My only issue is that it should be a subclass of error_context, but at the moment I don't have a good way to refactor context() for it (I was reviewing that code from web interface only atm). Methinks it's better if you pull in the code and we'll see if we tweak it further.