Comments (7)
Agreed, perhaps such logic would be best handled by the parent. I'll have a think about it and if I do get some time I might take a look and PR my changes.
Looking forward to seeing this project evolve, will definitely be keeping a close eye on things and contributing where I can!
from eject.
Perhaps it is necessary to allow property values that are XML elements to be specified as Property
s for ObjectDefinition
s also (with a new ValueFormat
) whilst maintaining their current creation logic. That way that can be specified as initialiser parameters. Thoughts?
from eject.
I think ideally properties that are represented by XML elements should be treated equally as those represented by XML attributes.
from eject.
Yea, exactly. Adding a ValueFormat
like node
should make our model declare all the information we. A few notes with some more of my thoughts:
-
There are tons of tree associations, and not modeling these properties really helps reduce scope. It would be nice to have a pattern that allowed specifying the node associations if needed (for ignoring and injecting), but for it to default to the current behavior so we don't have to model everything.
-
The pattern of specifying builders is separate from the
ObjectDefinition
, since not all nodes define objects. I did some initial work, where aBuilder
could also conform toBuilderLookup
, and if it did, would define a scope of valid for sub-builders, but I realized that I could avoid the behavior for now. The key-value contract is pretty robust here, although I currently have to do the exclusions globally which is ugly, but not a huge concern. -
I'd love to gather more cases where this is needed for now.
frame
is the only one I remember, and I'm disabling frame generation so it's not a big problem.
from eject.
Interesting, thanks for explaining some of your thoughts.
-
I see where you are coming from, it's a trade up between verbosity and automation/dynamic behaviour. I agree that such optional specification falling back to the current behaviour would be the best for now. The only concern would be that it would not be immediately clear from looking at the builders why some element-based properties are specified and others are not compared to attribute-based properties where all are.
-
What would be the advantage of scoped builders? I currently like the implementation where builders are global and need not be defined per
ObjectDefinition
. Perhaps it would be best to scope exclusions as opposed to the inverse of scoping builders? (assuming I understand correctly) -
There's
frame
,target
/action
forUIBarButtonItem
andeffect
forUIVisualEffectView
. Probably more. Though all of these don't have to be set in the initialiser.
from eject.
Yea, I think there are easier ways here than expanding BuilderLookup after looking things over. I think defering this logic to parent.definition
and then having the parent determine the association via the property associated with the key path should be a lot more concise. Also, I think the XIBDocument.Declaration
class can get removed and tracked via Property.AssociationContext
more consistently. If you have any other thoughts I'm all ears!
I'm probably not going to get a chance to work on this for a while, feel free to take a stab at it if you're interested. My next chunk of time is probably going to be focusing on enhancing the high level code generation API's and integrating with stencil
.
from eject.
I pushed up some improvements here, such that the property can provide a mapping for a child node. Turned out to be pretty easy, and I needed to do it to clean up the modeling of commands a bit in preparation for Stencil
.
I was able to get rid of a global hack for fontDescriptor
-> font
, but haven't looked at the bar item actions or visual effect. I'll log separate bugs for those.
Thanks for talking me through it though!
from eject.
Related Issues (20)
- variable names should be inferred from IBOutlets
- Create homebrew formula for easy installation HOT 1
- Download button HOT 1
- Syntax Highlighting HOT 1
- Use Anchorage edge shorthand where possible HOT 3
- UIDatePicker minuteInterval error HOT 2
- Disable frame generation properly
- States! HOT 1
- License? HOT 1
- Add support for SnapKit HOT 1
- Enhance Code Generation Options
- Add CLI support for configuring code generation
- Add xib diff to github PRs HOT 5
- Fix UIVisualEffectView
- UIBarButtonItem should inject target/action
- UIStackView may out of order HOT 1
- LayoutMargins not generated HOT 1
- Readme add some badges
- Support Safe Area Layout Guide HOT 1
- eject fails to build with Xcode 11 (swift 3 is unsupported)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eject.