Submitted by heyrocker on Mon, 02/25/2008 - 21:21.
Thanks for the long thoughtful comment.
Numeric IDs are a big problem, although so far I have avoided them. Both my existing modules (content copy and system settings form) rely on a text-based identifier. This makes them very easy to implement. I suspect a lot of other admin interfaces will be similar (for instance FAPI forms are always text-identifiable.) However when it gets into nodes and users and comments, things do indeed become much more tricky. I really dislike either of the core hacks to force IDs into a non-conflicting state. Your third solution is similar to what we're doing now, but you really have to have a well thought out plan in order for that to work. It's very easy to mess up. I have been thinking about ways to do more automated synchronization through my module, but as you say its very complicated.
One thing I have considered recently is making a CCK GUID field for all my content types. These would then be uniquely identified regardless of where they originated, and now synchronization is far easier. This could be adapted for users and comments as well most likely.
As far as your second point, for now I'm not planning on putting db schema changes into this. There is a (yes, tedious) process for this already and it works well and I'm more worried about things we don't have good solutions for.
I don't know enough about how the AHAH stuff is implemented at all, but i BELIEVE it is still FAPI behind the scenes, because there needs to be a way for the forms to degrade gracefully for non-javascript-enabled users. I hope so anyways!
I will be contacting a bunch of people when I get this turned into a proper project. I'll definitely be in touch then.
Thanks
Thanks for the long thoughtful comment.
Numeric IDs are a big problem, although so far I have avoided them. Both my existing modules (content copy and system settings form) rely on a text-based identifier. This makes them very easy to implement. I suspect a lot of other admin interfaces will be similar (for instance FAPI forms are always text-identifiable.) However when it gets into nodes and users and comments, things do indeed become much more tricky. I really dislike either of the core hacks to force IDs into a non-conflicting state. Your third solution is similar to what we're doing now, but you really have to have a well thought out plan in order for that to work. It's very easy to mess up. I have been thinking about ways to do more automated synchronization through my module, but as you say its very complicated.
One thing I have considered recently is making a CCK GUID field for all my content types. These would then be uniquely identified regardless of where they originated, and now synchronization is far easier. This could be adapted for users and comments as well most likely.
As far as your second point, for now I'm not planning on putting db schema changes into this. There is a (yes, tedious) process for this already and it works well and I'm more worried about things we don't have good solutions for.
I don't know enough about how the AHAH stuff is implemented at all, but i BELIEVE it is still FAPI behind the scenes, because there needs to be a way for the forms to degrade gracefully for non-javascript-enabled users. I hope so anyways!
I will be contacting a bunch of people when I get this turned into a proper project. I'll definitely be in touch then.